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FOREWORD 


The  U.S.  Army  Research  Institute  for  the  Behavioral  and 
Social  Sciences  supports  the  Army  with  research  and  development 
on  manpower,  personnel,  training,  and  human  performance  issues  as 
they  impact  the  development,  acquisition,  and  operational  perfor¬ 
mance  of  Army  systems  and  the  combat  readiness  and  effectiveness 
of  Army  units.  The  impact  of  behavioral  and  performance  issues 
on  the  effectiveness  of  Army  systems  and  units  is  in  part  a 
function  of  how  the  personnel  and  equipment  are  organized  to 
conduct  and  support  combat  operations.  The  Army  has  identified  a 
need  to  develop  tools  to  increase  the  efficiency  and  reliability 
of  the  process  of  designing  organizational  units.  The  Fort  Bliss 
Field  Unit  is  conducting  advanced  development  research  to  meet 
this  need. 

This  report  is  a  comprehensive  guide  on  how  to  use  a  com¬ 
puter-assisted  tool,  the  Crew  Requirements  Definition  System 
(CRDS) .  The  CRDS  is  a  model  building  aid  for  small  organiza¬ 
tional  units.  It  enables  analysts  and  researchers  to  study 
alternative  organizational  solutions  to  problems  in  small-unit 
performance  and  workload.  The  study  may  be  directed  at  the  ef¬ 
fects  of  variations  in  (a)  unit  composition  and  size,  (b)  task 
start  times  and  sequencing,  or  (c)  task  allocation  to  personnel 
or  equipment  items.  Since  the  CRDS  is  a  fully  computer-assisted 
task  performance  analysis  tool,  the  effects  of  these  variables 
can  be  examined  without  having  to  conduct  separate  field  studies 
for  each  design  alternative. 


The  research  and  development  program  that  led  to  the  CRDS 
described  in  this  User's  Guide  was  sponsored  by  the  Force  Design 
Directorate  for  the  Combined  Arms  Command  of  the  U.S.  Army  Train¬ 
ing  and  Doctrine  Command  (TRADOC) ;  both  the  R&D  program  and  this 
product  have  been  briefed  to  successive  Deputy  Chiefs  of  Staff 


for  Combat  Developments  at  Headquarters  TRADOC.  Prototypes  of 
the  CRDS  were  demonstrated  at  the  28th  Army  Operations  Research 
Symposium,  the  23rd  Meeting  of  the  Department  of  Defense  Human 
Factors  Engineering  Technical  Group,  and  the  33rd  Annual  Meeting 
of  the  Human  Factors  Society.  This  User's  Guide  is  keyed  to 
Version  1.0  of  the  CRDS  software,  which  is  being  released  in 


conjunction  with  the  Guide. 
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The  authors  owe  a  special  debt  of  gratitude  to  Robert  E. 
Robinson,  who  worked  with  a  subcontractor  and  then  as  a  con¬ 
sultant  to  the  prime  contractor  for  this  research  product, 

Science  Applications  International  Corp.  He  was  responsible  for 
designing  the  specifications  and  writing  the  source  code  for  the 
earliest  prototype  versions  of  the  CRDS  software.  He  was  always 
willing  to  respond  to  the  authors'  questions,  suggestions,  and 
concerns,  and  his  responses  were  always  helpful  and  appreciated. 
The  early  prototypes  of  the  CRDS  were  written  for  an  Apple 
Macintosh  personal  computer  system,  and  the  software  was  sub¬ 
sequently  converted  by  others  into  its  present  IBM-compatible 
format. 

This  User's  Guide  is  an  example  of  a  research  product  v;hose 
development  was  stimulated  by  a  close  and  cooperative  relation¬ 
ship  between  defense  laboratories  and  academic  centers.  In  par¬ 
ticular,  since  1980  the  U.S.  Army  Research  Institute  for  the 
Behavioral  and  Social  Sciences  (ARI)  and  the  Consortium  of  Uni¬ 
versities  of  the  Washington  Metropolitan  Area  (CUWMA)  have  com¬ 
bined  their  research  talents  and  skills  through  the  Consortium 
Research  Fellows  program.  The  first  author  was  a  graduate  stu¬ 
dent  in  the  Department  of  Psychology  at  New  Mexico  State  Univer¬ 
sity  when  he  was  selected  to  work  with  technical  and  analytical 
personnel  in  the  ARI  Field  Unit  at  Fort  Bliss,  Texas,  as  a  Re¬ 
search  Fellow. 

This  research  product  has  benefited  from  the  significant 
contributions  of  many  individuals.  First,  special  thanks  are  due 
to  those  from  the  Department  of  Army  force  development  community 
who  took  time  out  of  their  busy  schedules  to  serve  as  evaluators 
of  this  User's  Guide  and  the  CRDS  software.  The  comments  and 
suggestions  made  by  Charles  O.  Nystrom  and  William  R.  Sanders, 
listed  as  technical  reviewers  on  the  inside  front  cover,  were 
especially  appreciated.  They  and  all  the  other  users  of  earlier 
drafts  of  this  research  product  documented  and  shared  with  the 
authors  their  suggestions  for  improving  the  User's  Guide. 
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PART  ONE:  INTRODUCTION 


Purpose 


The  Crew  Requirements  Definition  System  (CRDS)  is 
a  computer-based  tool  developed  to  assist  in  the 
creation,  evaluation,  and  modification  of  small  unit  or 
crew  designs.  For  the  CRDS,  a  crew  design  is  described 
as  a  scheme  or  model  that  specifies  the  numbers  and 
types  of  personnel  and  tasks  assigned  to  the  crew  and 
defines  the  time-based  task  network  and  the  assignment 
of  personnel  to  perform  each  task.  After  the  user  has 
collected  and  entered  the  data  necessary  to  describe  an 
initial  crew  design,  the  CRDS  enables  the  user  to 
specify  and  evaluate  alternatives  to  that  design.  The 
resulting  creation  and  evaluation  of  alternative  crew 
designs  is  both  efficient  and  cost  effective,  largely 
because  real  or  potential  design  problems  can  be 
identified  without  having  to  conduct  separate  field 
studies  for  each  design  alternative. 

This  User's  Guide  is  not  a  simplified  step-by-step 
outline  for  how  to  use  the  CRDS.  Rather,  it  describes 
the  underlying  rationale,  capabilities,  and  features  of 
the  CRDS  in  addition  to  giving  instructions  and 
examples  for  its  use. 

Background  of  the  CRDS 

The  CRDS  was  originally  envisioned  to  be  one 
component  of  a  larger  computer  software  package  called 
the  Systematic  Organizational  Design  (SORD)  methodology 
(see  Christ,  Conroy,  &  Briggs,  1990,  and  Kellner, 
Conroy,  &  Christ,  1992) .  The  SORD  methodology 
standardizes  the  process  and  structure  for  creating  and 
documenting  initial  organizational  concepts  in  the 
design  of  Army  units  up  through  company  size.  The 
technology  built  into  the  SORD  methodology  has  been 
transferred  to  the  U.S.  Army  Training  and  Doctrine 
Command  (TRADOC)  and  will  soon  become  the  required, 
standard  technique  for  designing  Army  units. 

However,  since  the  proponent  of  the  SORD 
methodology  (the  U.S.  Army  Combined  Arms  Command)  is 
principally  responsible  for  integrating  the 
organizational  concepts  created  by  separate  functional 
areas  or  branches  into  combined  arms  forces,  there  was 
no  need  to  incorporate  a  crew  design  capability  into 
the  SORD  methodology.  The  crew  designs  developed  at 
the  functional  area  or  branch  level  are  used  by  the 
force  designers  as  building  blocks  in  the  design  of  the 
higher  echelon  forces.  Consequently,  the  crew  design 
capability  of  the  CRDS  was  not  incorporated  into  SORD, 
but  rather  was  designed  as  a  stand-alone  tool. 
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As  it  currently  exists,  the  CRDS  is  useful  in  any 
military  or  civilian  situations  in  which  there  is  a 
need  to  develop  and  evaluate  alternative  small  unit 
designs.  The  system  is  not  application  specific,  but 
rather  can  be  used  whenever  the  user  has  some  knowledge 
or  educated  assumptions  about  the  tasks  the  small  unit 
is  to  perform,  the  types  of  personnel  assigned  to 
perform  the  tasks,  any  task  network  requirements,  and 
the  time  required  to  perform  each  task. 

The  CRDS  is  most  appropriate  for  the  development 
of  low  echelon,  specialized  organizational  units. 

These  types  of  units,  generally  called  crews  or  cells, 
tend  to  be  small  in  terms  of  the  number  and  types  of 
personnel  and  equipment  assets  assigned  to  them. 
Henceforth,  this  User's  Guide  refers  to  these  types  of 
low  echelon  units  as  crews  or  cells. 

Unless  otherwise  specified,  a  crew  is  the  small, 
specialized,  low  echelon  unit  of  concern  in  the  CRDS. 

In  the  present  context,  a  crev  refers  to  the  personnel 
that  operate,  maintain,  or  otherwise  service  a  specific 
crew-served  materiel  system.  For  example,  combat  and 
materiel  developers  are  concerned  with  designing  cost 
and  operationally  effective  crews  for  materiel  systems 
such  as  a  howitzer,  tank,  helicopter,  or  missile 
launcher. 

However,  the  CRDS  can  also  be  used  effectively  to 
design  an  organizational  cell.  A  cell  refers  to  the 
personnel  and  equipment  assets  which  jointly  perform  a 
set  of  mission  essential  tasks.  The  personnel  and 
equipment  assigned  into  a  cell  are  those  necessary  to 
provide  functions  such  as  those  associated  with  a  fire 
direction  center,  mess  section,  maintenance  team,  or 
forward  area  refueling  unit. 


Caveat  on  the  Terminology  and  Routines  Used  in  the  CRDS 

Because  of  its  genesis,  the  CRDS  retains  much  of 
the  flavor  and  terminology  that  are  perhaps  more 
appropriate  in  the  design  of  larger,  more  diverse 
higher  echelon  organizational  units.  However,  unless 
new  funds  are  made  available  to  enhance  the  CRDS 
software,  the  current  software  must  be  considered  the 
final  version.  The  funds  and  other  means  necessary  to 
modify  the  software,  to  include  the  wording  and  format 
of  input  and  output  video  display  screens,  simply  are 
no  longer  available  to  the  authors  of  this  manual. 

It  is  important  to  note  that  there  are  some 
potential  problems  in  the  current  CRDS  software.  For 
example,  the  CRDS  will  prompt  the  user  to  specify  the 
number  and  types  of  resources  assigned  to  a  crew  for 
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performing  its  mission  essential  tasks.  While  most 
users  of  the  CRDS  will  consider  these  resources  to  be 
soldiers,  with  specified  military  occupational 
specialties  (MOS)  and  skill  levels,  the  CRDS  permits 
the  resources  of  a  crew  to  be  either  personnel  or 
equipment  items  (or,  for  that  matter,  software 
programs) .  This  more  general  treatment  of  the 
resources  available  to  a  crew  greatly  enhances  the 
robustness  of  the  CRDS.  However,  to  improve  the 
intelligibility  of  this  User's  Guide  for  a  typical 
user,  the  term  "resource"  that  appears  in  a  CRDS 
display  will  be  translated  in  the  Guide  to  mean 
personnel  or  crew  member,  unless  otherwise  specified. 

More  generally,  the  User's  Guide  has  been  written 
to  take  into  account  any  and  all  potential  problems 
that  have  been  identified  in  the  software. 

Fortunately,  the  existence  of  potentially  confusing 
terminology  on  a  computer  monitor  or  screen  is  not  a 
great  problem.  The  user  can  gain  great  benefit  from 
the  aids  provided  by  the  CRDS  in  spite  of  this 
nuisance.  Likewise,  because  there  is  considerable 
redundancy  in  the  various  CRDS  outputs,  the  fact  that  a 
given  type  of  output  may  not  be  absolutely  reliable 
does  not  invalidate  the  information  that  is  available 
in  other,  perfectly  reliable  outputs. 


overview  of  the  User's  Guide 

T1  -emainder  of  the  CRDS  User's  Guide  is 
organized  into  the  following  parts: 

Part  Two:  Overview  of  the  CRDS  Methodolocrv 

Part  Two  contains  a  description  of  the  objectives, 
approach,  and  some  possible  applications  of  the 
CRDS.  A  <^ick  reference  for  using  the  CRDS  is 
also  provided. 

Part  Three:  Installing  and  Understanding  the  CRDS 

Part  Three  is  a  description  of  hardware  and 
software  requirements  of  the  CRDS,  as  well  as 
procedures  for  installing  and  activating  the  CRDS. 
This  part  also  contains  a  discussion  of  the  basic 
features  of  the  user-CRDS  interface  and  procedures 
for  managing  CRDS  data  files. 

Part  Four:  Building  a  CRDS  Data  File 

Part  Four  is  a  description  and  discussion  of  the 
detailed  step-by-step  procedure  for  building  a 
CRDS  data  file.  In  order  to  make  this  procedure 
as  clear  as  possible,  the  user  is  instructed  and 
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encouraged  to  build  a  prototype  data  file  or 
template  for  the  crew  of  a  representative  weapon 
system. 

Part  Five:  Viewing  and  Printing  CRDS  Output 

Part  Five  contains  a  discussion  of  the  information 
available  in  the  tabular  and  graphic  outputs  of 
the  CRDS  and  the  procedures  for  accessing  and 
printing  hard  copies  of  this  information. 

Part  Six;  Modifying  Template  Features 

An  analysis  of  the  organizational  design  of  a  crew 
often  suggests  that  the  initial  design  contains 
some  real  or  potential  problems.  Part  Six  of  the 
User's  Guide  describes  techniques  available  with 
the  CRDS  to  quickly  and  iteratively  modify  the 
original  design  of  the  crew. 

Part  Seven:  Sample  Problems 

Part  Seven  describes  and  discusses  two  sample 
applications  of  the  CRDS,  one  for  the  crew  of  a 
weapon  system  and  the  other  for  a  cell  of 
personnel  assigned  to  a  fire  direction  center. 

Also  included  in  this  part  of  the  Guide  are 
suggestions  for  handling  these  and  other  types  of 
data  sets. 


Part  Two  may  be  treated  as  a  supplemental  section 
of  the  User's  Guide.  The  CRDS  software  is  sufficiently 
user  friendly  that  a  user  could  skip  the  overview  of 
the  CRDS  in  Part  Two  and  proceed  directly  to  subsequent 
parts  of  the  Guide.  However,  it  is  suggested  that  all 
prospective  users  of  the  CRDS  carefully  read  Parts 
Three  through  Seven,  preferably  while  simultaneously 
interacting  with  the  CRDS  as  the  software  is  loaded  and 
operated  on  a  personal  computer. 


User  Characteristics 

Since  this  User's  Guide  is  not  a  primer  on  the 
various  operations  research  techniques  upon  which  the 
CRDS  relies,  the  user  should  have  some  knowledge  of 
these  techniques  to  use  the  system  most  effectively. 

What  is  most  necessary  is  that  the  user  have  an 
understanding  of  the  mission  essential  tasks  that  are 
to  be  performed,  the  personnel  and  equipment  items 
available  to  perform  the  tasks,  the  performance 
duration  of  each  task,  and  any  constraints  on  task 
sequencing.  It  is  preferable  that  the  user's 
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understanding  of  the  crew  requirements  be  based  on 
personal  experience  in  observing  crews  actually 
performing  mission  essential  tasks. 
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Objectives 


The  CRDS  is  a  task  performance-based  model 
building  aid  for  crews.  As  such,  the  CRDS  can  serve 
as;  (a)  a  generator  of  graphic  aids  for  the  study  and 
analysis  of  crew  design  and  performance;  (b)  a  source 
of  insights  and,  hence,  a  point  of  departure  for 
alternative  crew  designs;  and  (c)  an  archive  of 
previously  designed  crews  for  study  and  briefing. 

In  a  general  sense,  the  CRDS  enables  the  user  to 
examine  alternative  organizational  solutions  to 
problems  associated  with  excessive  crew  workload.  In 
the  CRDS,  excessive  crew  workload  is  defined  in  terms 
of  (a)  an  excessive  amount  of  time  or  number  of  crew 
members  required  to  perform  mission  essential  tasks  or 
(b)  an  excessive  demand  on  individual  crew  members  to 
perform  multiple  tasks  simultaneously. 

In  all  these  regards,  the  objectives  of  the  CRDS 
are  to  aid  the  user  in  accomplishing  the  following: 

1.  To  minimize  mission  performance  time  along 
the  longest  duration  path  of  the  task 
performance  network. 

2 .  To  minimize  the  number  of  crew  members 
required  for  a  specified  task  performance 
network  and  mission  performance  time. 

3.  To  further  minimize  the  number  of  crew 
members  required  at  the  expense  of  increased 
mission  performance  time. 

4.  To  minimize  the  occurrence  of  time  intervals 
during  which  one  type  of  crew  member  has  two 
or  more  tasks  to  perfomn  simultaneously. 

The  CRDS  enables  analysts  and  researchers  to  study 
the  performance  of  alternative  crew  designs  in  a  timely 
and  cost  effective  manner.  The  study  may  be  directed 
at  the  effects  on  mission  performance  time  of 
variations  in  (a)  crew  composition  and  size,  (b)  task 
start  times  and  task  sequencing,  or  (c)  task  allocation 
to  crew  members.  Since  the  CRDS  is  a  fully  computer- 
assisted  task  performance  analysis  tool,  the  effects  of 
these  variables  can  be  examined  without  the  need  to 
observe  crews  actually  performing  their  duties  in  each 
of  the  alternative  crew  designs. 
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Approach 


The  CRDS  has  three  key  features  which  contribute 
to  its  ease  of  use  while  attaining  its  objectives. 

These  key  features  of  the  CRDS  are: 

•  Pre- formatted  crew  data  files  or  templates, 

•  A  problem-solving  structure  based  upon  critical 
path  analysis,  and 

•  Highly  useful  graphic  and  tabular  data 
sximmaries. 

Each  of  these  features  is  described  in  succeeding 
paragraphs . 


Crew  Data  Files  or  Templates 

The  development  and  documentation  of  detailed 
descriptions  of  crews  are  some  of  the  most  tedious 
aspects  of  the  crew  design  process.  This  is  especially 
true  if  time-based  task  networks  are  part  of  the  crew 
description.  The  automated  features  of  the  CRDS 
provide  the  user  with  an  interactive,  graphic 
capability  to  easily  and  rapidly  develop  and  document 
these  types  of  crew  models. 

In  the  CRDS,  the  model  which  describes  the 
composition,  organization,  and  structure  of  a  crew  is  a 
highly  preformatted  data  file  or  template  that  can  be 
easily  filled,  changed,  updated,  or  copied.  Five  types 
of  data  must  be  entered  to  establish  a  template.  They 
are: 

•  The  number  and  names  of  different  types  of  crew 
members  (e.g.,  the  number  of  each  type  of  crew 
member  NOS  and  skill  level) , 

•  The  number  and  names  of  tasks  which  must  be 
performed  by  the  crew  members, 

•  Any  required  sequences  of  task  performance, 

•  The  assignment  of  different  types  of  crew 
members  to  perform  each  task,  and 

•  The  performance  time  measure  for  each  task. 

Some  of  these  data  may  be  derived  from  the  required 
mission  capabilities  of  the  higher  echelon  unit  to 
which  the  crew  under  consideration  is  assigned.  Other 
data  may  be  obtained  from  the  operational  requirements 
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documents  and  target  audience  descriptions  of  the  major 
materiel  system  to  which  the  crew  is  assigned. 

Ideally,  performance  time  data  should  be  derived  from 
field  observations. 

The  CRDS  may  be  used  to  build  a  new  crew  template 
or  to  access  an  existing  template  that  was  previously 
developed  and  stored.  In  either  case,  the  CRDS 
supports  template  creation  and  modification  by  allowing 
the  user  to  save  changes  to  a  crew  data  file  at  any 
time. 


Critical  Path 

The  CRDS  incorporates  a  critical  path  approach  to 
the  development  and  evaluation  of  crew  models.  This 
approach  builds  on  the  time-based  task  network 
structure  of  a  crew  template.  The  CRDS  automatically 
calculates  the  critical  time  path  based  upon  task 
performance  times  and  task  contingencies. 

A  critical  path  or  critical  sequence  of  tasks  is 
defined  as  that  sequence  of  task  performance  which 
consumes  the  most  time  from  the  initiation  to  the 
completion  of  the  mission.  Each  successive  task  in  the 
critical  task  sequence  must  be  completed  before 
performance  of  the  next  task  in  the  sequence  can  begin. 
By  definition,  there  is  no  idle  time  in  the  critical 
task  sequence;  all  crew  member  performance  time  on  the 
critical  path  is  productive  time. 

While  all  tasks  assigned  to  the  crew  are  mission 
essential  tasks,  not  all  tasks  are  on  the  critical 
path.  The  performance  of  mission  essential  tasks  which 
are  not  on  the  critical  path  have  start  and  end  times 
which  can  vary.  Personnel  performing  tasks  which  are 
not  in  the  critical  task  sequence  have  idle  time  either 
before  task  performance  begins  or  after  task 
performance  is  completed. 

Consider  a  very  simple  example.  Assume  that  the 
mission  of  a  crew  requires  the  performance  of  four 
distinct  tasks,  called  Task  A,  Task  B,  Task  C,  and  Task 
D,  respectively.  Furthermore,  assume  that  a  different 
crew  member  is  assigned  to  perform  each  task  and  that 
the  time  required  to  perform  each  task  is  exactly  one 
minute.  Finally,  assume  that  Task  D  may  be  performed 
at  any  point  during  the  total  mission  duration,  but 
that  Tasks  A,  B,  and  C  must  be  performed  in  series. 

In  this  example,  the  critical  path  is  defined  as 
the  sequence  of  performing,  in  order.  Tasks  A,  B,  and 
C,  and  the  time  required  to  perform  this  sequence  of 
task  (i.e.,  three  seconds)  is  the  mission  completion 
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time.  There  is  no  idle  time  during  the  performance  of 
these  three  tasks;  each  of  the  three  designated  crew 
members  initiate  the  performance  of  their  assigned 
tasks  as  soon  as  possible.  On  the  other  hand,  the  crew 
member  assigned  to  Task  D  has  a  choice  concerning  when 
that  task  will  be  performed.  Task  D  may  be  initiated 
simultaneously  with  Task  A,  in  which  case  there  will  be 
two  seconds  between  the  completion  of  Task  D  and  the 
completion  of  the  total  mission.  Alternately,  the 
initiation  of  Task  D  can  delayed  up  to  two  seconds 
after  that  of  Task  A,  in  which  case  there  will  be  up  to 
two  seconds  of  idle  time  prior  to  its  initiation. 

The  duration  of  the  critical  path  sequence  is  a 
key  indicator  of  the  efficiency  of  the  crew  model.  For 
a  less  than  optimally  efficient  model,  the  duration  of 
the  critical  path  sequence  can  be  reduced  through 
changes  in  the  crew  design,  e.g.,  changes  in  task 
timing  or  in  the  allocation  of  tasks  to  crew  members. 

Studying  the  critical  path  also  enables  the  user 
to  evaluate  the  level  of  workload  imposed  on  crew 
members.  In  the  context  of  a  time-based  task  analysis, 
workload  can  be  related  to  time  stress,  and  defined  as 
the  time  required  to  perform  a  task  or  set  of  tasks 
(Tg)  divided  by  the  time  available  (T^)  ,  yielding  the 
ratio  T^/T^.  In  a  scenario  with  no  time  stress,  Tp  is 
less  than  T^.  As  Tp  increases  and  approaches  T^, 
increasing  amounts  of  workload  are  imposed  on  the  crew 
member  performing  the  tasks  and,  more  generally,  on  the 
crew.  If  Tp  exceeds  T^  (i.e.,  if  the  time  required  to 
perform  a  task  or  set  of  tasks  exceeds  the  performance 
time  available) ,  mission  performance  may  suffer. 

In  summary,  knowing  which  tasks  are  in  the 
critical  task  sequence,  the  task  performance  times,  and 
which  type  of  crew  member  is  assigned  to  perform  the 
tasks  provides  a  powerful  basis  for  evaluating  the 
efficiency  of  the  crew  design. 


Graphic/Visual  Aids 

Once  an  initial  crew  design  has  been  developed, 
its  characteristics  should  be  capable  of  study, 
analysis,  and  modification.  The  goal  is  to  understand 
the  impact  of  the  crew  design  data  and  possible  changes 
in  those  data  on  a  set  of  mission  or  system  functions. 
However,  even  with  a  relatively  simple  initial  crew 
design,  there  are  likely  to  be  very  many  feasible  sets 
of  alternative  crew  data  files.  Manually  creating 
graphic  and  tabular  summaries  for  each  of  these 
alternatives  represent  a  huge  undertaking,  one  which 
substantially  lengthen  the  total  crew  design  process. 
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The  CRDS  is  designed  to  overcome  these  problems. 
The  underlying  basis  of  the  CRDS  is  several  automated 
critical  path  method  calculations  and  summaries.  In 
addition,  the  system  produces  other  automated 
calculations  and  summaries  to  aid  the  user.  These 
computer  assisted  portrayals  of  crew  data  files  are 
completed  very  guickly. 

Furthermore,  the  examination  and  manipulation  of 
crew  data  files  are  easy,  because  the  CRDS  allows  the 
user  to  see  the  various  time-based  relationships  among 
tasks,  task  sequences,  personnel,  task  allocation  to 
personnel,  and  mission  performance  time.  The  CRDS 
automatically  creates  timelines  and  other  graphic  and 
tabular  representations  of  the  crew  data  file.  These 
representations  of  the  data  permit  the  user  to  gain 
insights  into  key  relationships  in  the  crew  design. 
Furthermore,  the  methods  for  presenting  the  data  are 
such  that  they  aid  the  user  in  developing  'insights'  to 
procedures  that  can  be  used  to  improve  the  design  of 
the  crew. 

If,  after  creating  an  initial  crew  design,  the 
user  wishes  to  create  or  develop  a  variation  of  that 
design  (e.g.,  insert  a  change  in  required  task 
sequencing) ,  the  CRDS  provides  the  capability  to  create 
alternate  files  and  maintain  a  copy  of  each 
modification  as  new  variations  on  the  original  design 
are  created. 

Taken  together,  these  features  of  the  CRDS  provide 
the  user  with  the  capability  to  develop  organizational 
models  of  crews  and  to  subsequently  modify  those 
models  in  an  interactive  graphic  fashion.  In  addition, 
the  CRDS  provides  the  user  with  the  capability  to 
translate  any  of  the  resulting  graphic  model 
specifications  directly  into  a  report  or  briefing 
format.  The  user  may  print  permanent  records  and 
graphs  for  archival  and  briefing  purposes. 


Conflict  Resolution 

The  CRDS  uses  the  presence  of  task  conflicts  as 
the  principal  indicator  that  the  crew  model  can  be  made 
more  efficient.  In  the  CRDS,  a  task  conflict  exists 
whenever  two  or  more  tasks  whose  performance  overlap  in 
time  are  assigned  to  one  type  of  crew  member.  If,  for 
any  reason,  the  simultaneous  performance  of  two  or  more 
tasks  by  one  type  of  crew  member  is  not  possible,  the 
tasks  are  considered  in  conflict. 

The  CRDS  offers  four  ways  to  resolve  or  eliminate 
conflicts  in  task  performance. 
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•  Change  the  timing  of  the  tasks.  The  user 
reschedules  otherwise  conflicting  tasks 

so  that  their  respective  performances  occur 
during  non-overlapping  time  intervals  in  the 
time-based  task  network.  In  practice,  this 
solution  typically  delays  the  start  times  of 
one  or  more  of  the  conflicting  tasks  so  that 
a  specified  type  of  crew  member  can  perform 
each  of  the  tasks  during  different  time 
intervals . 

•  Change  the  assignment  of  crew  members  to  tasks. 
After  examining  the  crew  model,  the  user 
identifies  other  types  of  available  crew 
members  to  whom  one  or  more  conflicting 

tasks  may  be  allocated.  These  other  types  of 
crew  members  must  be  idle  during  the 
intervals  in  which  the  newly  assigned  tasks  are 
to  be  performed  and  they  must  otherwise  have 
the  capability  to  perform  the  newly  assigned 
tasks . 

•  Change  the  reouirement  for  task  seguencing. 

The  user  redefines  the  sequence  in  which  tasks 
are  performed.  This  solution  can  only  be 
implemented  if  the  tactics,  techniques,  and 
procedures  of  operation  for  the  crew  are 
sufficiently  flexible  to  permit  a  change  in 
task  sequences.  Alternately,  this  solution 
requires  a  change  in  the  acceptable  operating 
characteristics  of  crew-served  materiel 
systems.  Such  conditions  are  likely  to  exist 
only  very  early  in  the  force  development  or 
system  development  cycle. 

•  Increase  the  number  of  crew  memhgrs  capable  of 
performing  conflicting  tasks.  The  user  assigns 
to  the  crew  additional  crew  members  of  the  type 
whose  task  performance  is  in  conflict.  In  this 
solution,  the  conflict  is  eliminated  since 
tasks  that  would  otherwise  be  in  conflict  are 
now  performed  by  different  crew  members  of  the 
seune  type.  For  example,  more  than  one  soldier 
with  a  given  MOS  and  skill  level  could  be 
allocated  to  the  tasks  whose  performances 
overlap  in  time. 

Other  solutions  to  the  conflicts  identified  in  the 
crew  model  are  also  possible,  but  they  may  not  be, 
strictly  speaking,  organizational  solutions.  For 
example,  the  recruitment,  selection,  training  and 
placement  of  personnel  could  represent  long-term 
solutions  to  task  performance  conflicts  in  a  crew. 
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Trade-offs  in  the  Development  of  crew  Designs 

The  reader  of  the  Guide  should  recognize  that 
potential  solutions  to  conflicts  identified  in  crew 
models  are  in  reality  sub-optimal  solutions.  There  are 
trade-offs  that  must  be  considered  in  the  efficiency, 
effectiveness,  and  cost  of  each  proposed  solution. 

For  example,  while  the  performance  start  time  of 
one  of  two  conflicting  tasks  may  be  delayed  to 
eliminate  an  instance  in  which  a  given  crew  member  is 
otherwise  required  to  simultaneously  perform 
incompatible  tasks,  this  solution  may  cause 
unacceptable  increases  in  the  overall  mission 
completion  time.  Alternately,  while  a  task  may  be 
reallocated  from  a  crew  member  with  no  idle  time  to  one 
with  idle  time,  this  change  in  task  allocation  may  also 
eliminate  the  desirable  'idle  time*  or  'rest'  in  a 
work-rest  cycle  that  is  otherwise  used  to  maintain  the 
performance  capability  of  the  crew  members.  The  most 
desirable  resolution  of  a  conflict  generally  will 
create  a  design  in  which  the  task  network  will  fall 
between  the  two  extreme  described  below. 

•  Task  Networks  in  which  All  Tasks  are  Performed 
in  Parallel.  In  this  case,  no  task  would  have 
a  required  predecessor  task  —  the  most 
pristine  form  of  task  relationships.  With  this 
arrangement,  there  is  no  shorter  total  mission 
performance  time  without  shortening  or  deleting 
long-duration  tasks.  This  arrangement, 
however,  requires  that  some  few  personnel  do 
many  tasks  simultaneously  or  that  there  are  a 
maximum  number  of  personnel  assigned  to  the 
crew,  one  per  task.  Practically  speaking  there 
are  prescribed  task  sequences,  but  there  is 
often  latitude  in  this  regard  early  in  the 
system  design  process,  and  some  tasks  may  be 
assigned  to  either  machines  or  people. 

•  Task  Networks  in  which  All  Tasks  are  Performed 
in  Series.  In  this  case,  every  task  has  a 
unique  required  predecessor  task.  The 
performance  of  each  task  can  begin  only  after 
its  predecessor  task  has  been  completed.  Since 
no  two  tasks  are  performed  in  parallel, there 
are  no  conflicts  in  task  performance.  The  crew 
is  more  economical  with  respect  to  the  demands 
on  crew  members  (none  is  required  to  perform 
more  that  one  task  at  a  time) .  Furthermore, 
there  is  a  minimum  requirement  for  alternative 
crew  members  —  one  very  capable  soldier  can 
perform  all  mission  essential  tasks.  However, 
this  purely  serial  arrangement  of  tasks 
maximizes  overall  mission  performance  time. 
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Clearly  there  are  many  optional  crew  models  for 
any  set  of  task  conditions  and  crew  member 
capabilities.  The  CRDS  permits  a  user  to  quickly 
create  the  more  feasible  models  and  provides  sufficient 
information  about  the  characteristics  of  those  models 
to  allow  a  useful  trade-off  determination. 


Quick  Reference  for  Using  the  CRDS 

This  section  summarizes  procedures  and  techniques 
for  using  the  CRDS.  After  actively  participating  in 
the  instructions  given  in  subsequent  parts  of  this 
User's  Guide  and  gaining  some  experience  in  using  the 
CRDS,  the  user  will  find  the  quick  reference  helpful. 


1.  Enter  data  required  to  develop  a  crew 
template  or  retrieve  a  previously  developed 
crew  template.  (See  Part  Four) 

Minimum  data  requirements: 

•  Number  and  names  of  different  types  of 
crew  members 

•  Number  and  names  of  tasks  to  be  performed 

•  Names  of  the  different  types  of  crew 
members  assigned  to  perform  each  task 

•  Task  sequence  information 

•  Performance  time  of  each  task 

2.  Calculate  the  critical  path.  (See  Part  Five) 

3.  Examine  and  print  hard  copies  of  template 
characteristics.  (See  Part  Five) 

4.  Modify  the  template,  as  necessary  and 
desirable,  to  attain  the  objectives  of  the 
particular  study.  (See  Part  Six) 

Obi ectives; 

•  Minimize  performance  times  along  the 
longest  duration  path  of  the  task 
performance  network 

•  Minimize  the  number  of  crew  members 
required  for  a  given  mission  time  and  task 
sequence 
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•  Further  minimize  the  required  number  of 
crew  members  at  the  expense  of  increased 
mission  time 

•  Minimize  the  occurrence  of  time  intervals 
during  which  one  type  of  crew  member  has 
multiple  tasks  to  perform  simultaneously 

Modification  Methods; 

•  Change  task  start  times 

•  Change  allocation  of  crew  members  to  tasks 

•  Change  task  sequence  requirements 

•  Increase  crew  size  by  increasing  the 
number  of  each  'overloaded'  crew  member 

Aids  to  Modification; 

•  Critical  task  list 

•  Conflict  overlap  table 

•  Conflict  adjustment  table  (task  start 
times  delays  within  or  outside  the  initial 
mission  time) 

•  GANTT  chart 

•  PERT  diagram 


The  remainder  of  this  User's  Guide  provides  a 
detailed  description  of  how  to  install  and  initiate  the 
CRDS,  and  a  description  and  explanation  of  each  major 
CRDS  function.  The  order  of  discussing  the  CRDS 
functions  is  the  same  as  the  order  in  which  the 
functions  are  listed  in  the  menus  of  options,  even 
though  the  user  may  not  typically  progress  through  them 
in  that  order.  Finally,  in  Part  Seven  of  the  User's 
Guide,  applications  of  the  CRDS  to  two  sample  problems 
are  presented. 
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Hardware  and  Software  Requirements 

The  following  hardware  and  software  are  necessary 
to  run  the  CRDS  program. 


1.  IBM  personal  computer  (PC)  or  100  percent 
compatible,  with  a  5  1/4  inch,  360  Kb  floppy 
disk  drive  designated  as  Drive  A. 

2.  PC  or  MS  DOS  VERSION  3.0  or  higher. 

3 .  Microsoft  Mouse  or  compatible  with  proper 
drivers. 

4.  A  locally  dedicated  IBM  Proprinter  or  Epson- 
compatible  printer. 

HOTE:  Laser  printers  are  incompatible  with  the  CRDS 
software  and  will  not  print  graphic  outputs  of  the 
CRDS. 

IMPORTANT:  The  Epson-compatible  printer  must  be  linked 
directly  to  the  parallel  output  port  designated  as 
LPTl.  If  the  PC  is  connected  to  the  printer  through  a 
local  area  network,  the  user  should  seek  assistance 
from  a  systems  manager. 

5.  One  of  the  following  graphics  adapters: 


Graphics  Device 

Resolution 

Colors 

AT&T  &  Compaq  III 

640 

X 

400 

monochrome 

AT&T  DEB  Graphics 

640 

X 

200 

16 

AT&T  DEB  Graphics 

640 

X 

400 

16 

IBM  Color  Graphics 

640 

X 

200 

2 

IBM  Color  Graphics 

320 

X 

200 

4 

Sigma  Design  Color-400 

640 

X 

400 

16 

Sigma  Design  Laser  View 

1664 

X 

1200 

4 

IBM  EGA 

640 

X 

200 

16 

IBM  EGA 

640 

X 

350 

monochrome 

IBM  EGA 

320 

X 

200 

16 

IBM  EGA 

640 

X 

350 

16 

IBM  MCGA 

640 

X 

480 

2 

IBM  EGA 

640 

X 

350 

2 

IBM  VGA 

640 

X 

480 

16 

IBM  VGA-analog 

320 

X 

200 

256 

MDS  Genius  Display 

736 

X 

1008 

monochrome 

Hercules 

720 

X 

348 

monochrome 

NEC  PC-98 00/VM 

640 

X 

400 

16 
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Graphics  Device 

NEC  PC--9800/VM 

Tseng  Labs  EVA/480 

NDI  Genesis  1024-digital 

NDI  Genesis  1024-analog 

NDI  Genesis  1024-JVC 

NDI  Genesis  1024-Mitsubishi 

NDI  Genesis  1280-JVC 

Number  Nine  Revolution,  111008 

Toshiba  3100 

Tecmar  Graphics-Master 

STB  GraphicsPlus-II 

STB  GraphicsPlus-II 

STB  GraphicsPlus-III 

Tecmar  Graphics-Master 

Tecmar  Graphics-Master 

Tecmar  Graphics-Master 

Tecmar  Graphics-Master 

Video-7  Vega  Deluxe 

Video-7  Vega  Deluxe 

Video-7  VGA 

Video-7  VGA 

Paradise  Auto  EGA/480 

Genoa  SuperEGA  HiRes 

Everex  Edge 

Everex  Edge 

WYSE  wy-700  Display 

WYSE  WY-700  Display 

WYSE  WY-700  Display 

IBM  3270  PC 


Resolution  Colors 


640 

X 

400 

2 

640 

X 

480 

16 

640 

X 

480 

16 

640 

X 

480 

16 

1024 

X 

768 

16 

1024 

X 

768 

16 

1280 

X 

1024 

16 

512 

X 

512 

256 

640 

X 

400 

monoch 1 ome 

720 

X 

352 

monochrome 

640 

X 

352 

monochrome 

320 

X 

200 

16 

640 

X 

400 

monochrome 

720 

X 

704 

monochrome 

640 

X 

200 

16 

640 

X 

400 

16 

320 

X 

200 

16 

640 

X 

480 

16 

752 

X 

410 

16 

720 

X 

540 

16 

oJO 

X 

600 

16 

.;4u 

X 

480 

16 

800 

X 

600 

16 

640 

X 

200 

16 

640 

X 

400 

16 

640 

X 

4Uu 

monochrome 

I'.iO 

X 

400 

monochrome 

1280 

X 

800 

monochrome 

720 

X 

350 

monochrome 

Conventioas  of  This  User's  Guide 

CRDS  Screens 


A  complete  CRDS  screen  will  always  be  shown  within 
a  box,  either  a  box  in  the  shape  of  the  screen  or  a 
smaller  one  such  as  the  following. 


Enter  task  01  name  with  a  maximum  of  10  characters 
>  Attend  Sen 

PRESS  RETURN  TO  CONTINUE 


Figure  1.  Illustration  of  a  complete  CRDS 
screen. 
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References  tio  Specific  Features  of  CRDS  Screens 

References  to  specific  features  of  CRDS  screens, 
whether  menu  options  or  prompts  to  the  user,  will  be 
shown  in  this  guide  within  quotation  marks  and,  as 
nearly  as  possible,  just  as  they  appear  in  the  CRDS 
screen  (e.g.,  "BUILD  TEMPLATE"  and  "GANTT  Timelines"). 

User  Input 


Prompted  user  input  will  always  be  shown  in  bold 
type  and  capital  letters  and  will  be  enclosed  within 
quotation  marks  (e.g.,  "USER  INPUT").  You  should  not 
include  the  quotation  marks. 

Important  Messages 

Important  messages  appear  in  bold  type  without 
quotation  marks  and  are  preceded  by  an  alerting  word 
such  as  MOTE  or  IMPORTANT  (see  Page  17  for  examples) . 


Software  Installation 

To  install  the  CRDS  software,  the  following 
actions  need  to  be  taken. 

1.  Insert  Diskette  #1  of  the  CRDS  software 
(labelled  CRDSl)  into  Drive  A  of  the  system 
on  which  the  CRDS  is  to  be  resident. 

2.  Change  to  the  A:  disk  drive  by  typing  "A:" 
and  pressing  <Return>  —  (<Enter>  on  some 
systems) . 

3.  Run  the  install  program  (a  batch  program) 
by  typing  "INSTLCRD"  and  then  pressing  the 
<Return>  key.  The  install  program  will 
prompt  the  user  to  remove  "CRDSl"  and  insert 
"CRDS2".  Then,  the  install  program  will 
create  a  directory  called  "CRD"  on  the  C: 
drive  and  copy  the  CRD  files  to  that 
directory.  After  the  installation  procedure 
is  complete,  the  prompt  "C:\CRD"  will  appear. 
This  indicates  that  the  user  is  in  the  newly 
created  CRD  directory. 


Getting  Started 


If  the  system  on  which  the  CRDS  is  resident  has 
been  rebooted  or  turned  off  since  the  CRDS  software  was 
last  used,  the  following  actions  need  to  be  taken  in 
order  to  use  the  CRDS. 
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1.  At  the  ''C:\CRD"  prompt  of  the  DOS 
environment,  type  "METAWNDO"  and  press 
<Return>.  This  action  causes  the  graphics 

^  program  to  be  run. 

2.  Type  ''PRTSCRN”  and  press  <Return>.  This 
causes  the  printer  driver  program  to  be  run. 

3.  Type  "INST_CRD'*  and  press  <Return>  to  run  the 
graphics  adapter  program.  (Note  that  this 
action  needs  to  be  taken  only  once,  not  every 
time  you  boot  your  system.)  The  user  will  be 
prompted  for  the  desired  graphics  and  print 
software  from  the  host  system  and  will 
receive  a  series  of  prompts  to  be  answered 
either  by  typing  a  "Y''  for  yes  or  an  "N"  for 
no.  Normally,  the  user  will  type  "Y"  in 
response  to  each  query. 

4 .  Type  ''CRD”  and  press  <Return>  to  run  the  CRDS 
program.  This  will  cause  the  CRDS  "MAIN 
OPTIONS"  menu  to  appear,  as  illustrated  in 
Figure  2  below. 


MAIN  OPTIONS 
FILES 

BUILD  TEMPLATE 
CALCULATE  CRITICAL  PATH 
DISPLAY  PERT/GANTT 
PRINT  OPTIONS 
ESC 


Figure  2.  The  CRDS  Main 
Options  Menu 


The  CRDS  Main  Options  Menu 

The  options  in  the  main  menu,  when  selected,  may 
cause  additional  menus  to  appear.  Each  of  the  main 
options  is  briefly  described  below. 

FILES:  The  "FILES”  option  displays  a 

menu  allowing  the  user  to  read 
or  save  a  template,  or  to  view 
the  template  directory. 

BUILD  TEMPLATE:  The  "BUILD  TEMPLATE"  option 

displays  a  menu  allowing  the 
user  to  create  a  new  CRDS 
database  or  template. 
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CALCULATE  CRITICAL  PATH:  This  option  causes  the 

critical  path  to  be 
calculated,  allowing  the  user 
to  access  the  various  output 
formats  offered  by  the  CRDS. 

DISPLAY  PERT/GANTT:  This  option  displays  a  menu 

containing  the  various  output 
formats  offered  by  the  CRDS. 

PRINT  OPTIONS:  This  option  displays  options 

for  printing  the  inputs  to  a 
CRDS  data  file. 


Selecting  Menu  Options  in  CRDS 

To  access  menu  options  in  the  CRDS,  perform  the 
following  steps: 


1.  Use  the  arrow  keys  to  move  the  reverse  video 
bar  (the  highlighted  portion  of  the  screen) 
over  the  option  to  be  selected. 

2.  Press  the  <Return>  key. 


The  options  in  a  CRDS  menu  can  also  be  selected  by 
pressing  the  letter  in  each  option  that  appears  in 
boldface.  For  example,  the  user  can  access  the  "BUILD 
TEMPLATE"  option  by  pressing  "B" . 


MOTE:  Selecting  some  options  of  the  main  menu  will  not 
produce  a  response  unless  appropriate  inputs  have  been 
previously  made  to  other  options.  For  example,  the 
"PRINT  OPTION*'  of  the  main  menu  is  not  activated  if  a 
template  has  not  been  build  or  read  into  the  computer 
memory  and  if  the  critical  path  of  that  template  has 
not  been  calculated. 

Pressing  <Esc>  causes  the  system  to  return  to  a 
previous  screen  or  menu.  Pressing  <Bsc>  when  in  the 
main  menu  or  selecting  the  "ESC"  option  of  the  main 
menu  causes  the  system  to  exit  to  the  DOS  environment. 


File  Management 


Selecting  the  "FILES"  option  of  the  CRDS  main  menu 
will  cause  the  "FILES  OPTIONS"  menu,  illustrated  in 
Figure  3,  to  appear. 
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FILES  OPTIONS _ 

READ  TEMPLATE  FROM  DISK 
SAVE  TEMPLATE  TO  DISK 
VIEW  TEMPLATE  DIRECTORY 
ESC  RETURN  TO  MAIN 


Figure  3.  The  CRDS  Files 
Options  Menu. 


The  items  in  the  "FILES  OPTIONS"  menu  enable  users 
to  save  files  and  access  them  at  a  later  time.  Each  of 
the  options  in  this  menu,  as  well  as  additional  file 
management  capabilities  provided  by  the  CRDS,  will  be 
discussed  in  the  present  section. 

Reading  CRDS  Data  Files  From  the  CRDS  Directory 

To  access  a  previously  saved  file  from  the  CRDS 
directory,  select  the  "READ  TEMPLATE  FROM  DISK"  option. 
The  files  directory  will  appear,  as  illustrated  in 
Figure  4.  File  names  are  selected  by  moving  the 
reverse  video  over  the  desired  menu  option  and  pressing 
<Return> .  ^ 

NOTE:  Valid  names  for  CRDS  data  file  or  template 
contain  one  to  eight  alphanumeric  characters.  These 
names  are  stored  in  the  CRDS  directory  and  displayed  in 
the  files  directory  as  an  eight  character-space  file 
name  (with  the  CRDS  using  underbars  to  fill  in  the 
eight  character  spaces,  if  necessary)  and  a  CRDS- 
supplied  three  character  extension  name  ".SRD.” 


SELECT 

FILE 

FDC _ 

__SRD 

TO  SELECT  A  FILE  PRESS  RETURN 

Figure  4.  Directory  of  saved  CRDS  data  files. 
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IMPORTANT:  Accessing  e  file  will  erase  from  memory  any 
data  currently  being  used  by  the  program.  Therefore, 
if  you  were  using  the  data  of  another  template  that  was 
not  already  saved,  as  described  in  the  next  subsection, 
then  you  will  lose  that  data. 

To  use  the  data  that  has  been  selected,  press 
<Esc>  to  return  to  the  "MAIN  OPTIONS"  menu.  To  exit 
the  "READ  TEMPLATE  FROM  DISK"  option  without  selecting 
a  file,  press  <Esc>  without  pressing  <Return>. 

NOTE:  For  the  purpose  of  facilitating  the  current 

instructions,  the  user  should  select  the  "READ  TEMPLATE 

FROM  DISK"  option,  select  the  file  "FDC _ .SRD",  and 

then  press  <Esc>  before  continuing  to  the  next 
subsection. 


Savina  CRDS  Data  Files  to  the  PC  Hard  Disk 

To  save  a  CRDS  template,  select  "SAVE  TEMPLATE  TO 
DISK"  of  the  "FILES  OPTIONS"  menu.  The  menu  for 
entering  a  file  name,  illustrated  in  Figure  5,  will 
appear.  Enter  the  desired  name  for  the  data  file  and 
press  <Return>. 


ENTER  A  FILE  NAME  MENU 

> _ 

PRESS  RETURN  WHEN  FINISHED 


Figure  5.  Box  allowing  CRDS  data  file  to  be 
saved . 


note:  The  user  need  only  enter  the  one  to  eight 
alphanumeric  character  name  for  the  data  file.  Upon 
saving  a  template,  the  CRDS  program  will  automatically 
insert  underbars  to  file  names  with  less  than  eight 
alphanumeric  characters  and  add  the  ".SRD"  extension 
name  to  the  file  name  of  all  data  files. 

IMPORTANT:  The  name  assigned  to  a  template  file  saved 
to  disk  must  be  unique  or  else  the  CRDS  will  write  over 
an  existing  file. 

The  "SAVE  TEMPLATE  OPTION"  can  be  used  only  if  the 
resources  and  tasks  of  a  template  have  been  defined.  If 
these  two  parameters  of  a  template  have  not  been 
previously  entered,  a  template  file  will  not  have  been 
created  and  hence  cannot  be  saved.  In  this  case,  the 
prompt  illustrated  in  Figure  5  will  not  be  displayed; 
the  user  must  press  <Esc>  to  return  to  the  main  menu. 
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The  "SAVE  TEMPLATE  TO  DISK"  option  allows  the  user 
to  create  duplicates  of  the  CRDS  data  files.  This 
feature  enables  the  user  to  edit  and  introduce  changes 
to  one  data  file  and  keep  the  other  unaltered. 

If,  following  the  instructions  of  the  previous 
subsection,  the  user  accessed  (i.e.,  read)  the  data 

file  named  "FDC _ .SRD,"  the  user  should  now  save 

that  data  file  with  a  new  name,  say,  FDC2.  Enter  this 
new  data  file  name,  press  <Return>,  and  then  press 
<Bsc>  to  return  to  the  main  menu.  By  following  these 
procedures,  the  data  file  directory  will  now  contain 

two  data  files,  FDC _ .SRD  and  FDC2 _ .SRD,  which 

contain  the  same  information. 

NOTE:  If  a  CRDS  data  file  is  duplicated,  any  editing 
changes  will  apply  only  to  the  copy  of  the  data  file 
currently  being  edited.  In  other  words,  changes  to  a 
data  file  will  apply  only  to  that  copy. 

viewing  the  List  of  CRDS  Data  Files  Stored  in  the  Directory 

To  view  the  CRDS  directory  of  template  files, 
select  the  "VIEW  TEMPLATE  DIRECTORY"  option.  A  screen 
like  that  illustrated  in  Figure  4  will  appear 
displaying  the  data  files  directory.  If  the  user  has 
followed  the  instructions  of  the  previous  two 

subsections,  this  directory  will  show  "FDC _ .SRD" 

and  "FDC2 _ .SRD"  as  the  names  of  two  templates. 

Even  though  the  screen  contains  the  message,  "TO 
SELECT  A  FILE,  PRESS  RETURN,"  the  user  will  not  be  able 
to  read  data  files  from  memory.  The  "VIEW  TEMPLATE 
DIRECTORY"  option  merely  allows  the  user  to  view  a 
listing  of  existing  CRDS  templates. 


CRDS  File  Management  in  the  DOS  Environment 
Transferring  CRDS  data  files 

The  user  may  transfer  a  CRDS  template  file  from 
one  system  to  another.  This  allows  CRDS  data  files  to 
be  examined  or  modified  by  subject  matter  experts  at 
more  than  one  location.  Transferring  CRDS  templates 
requires  copying  the  desired  data  file  from  the 
"C:\CRD"  directory  of  the  system  on  which  the  CRDS  is 
resident  to  another  directory,  normally  on  a  floppy 
diskette  that  has  been  inserted  into  a  floppy  diskette 
drive  of  the  system.  To  copy  a  file,  complete  the 
following  steps. 

1.  First  exit  the  CRDS  by  pressing  the  <Esc>  key 
repeatedly.  If  the  CRDS  data  file  has  not 
recently  been  saved,  a  warning  message  will 
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appear.  Upon  exiting  the  CRDS  program,  the 
prompt  "CrXCRD"  will  be  displayed,  indicating 
that  the  user  is  in  the  "CiXCRD"  subdirectory 
of  the  DOS  environment. 

2.  Entering  the  DOS  command  "Dir"  causes  all 
CRDS  files  to  be  listed.  All  files  that 
contain  CRDS  templates  or  data  files  are 
unique  because  of  their  ”.SRD"  extension 
names.  If  the  guidance  of  the  previous 
subsections  has  been  followed,  there  will  be 

one  data  file  named  "FDC _ .SRD”  and 

another  named  "FDC2 _ .SRD".  Assvime  that 

the  duplicate  file  is  to  be  copied. 

3.  Entering  the  DOS  command  "copy"  followed  by 
the  complete  name  of  the  CRDS  data  file  and 
the  name  of  the  external  drive  into  which  a 
diskette  has  been  inserted  will  cause  the 
file  to  be  copied  onto  that  diskette.  To 

copy  the  file  named  "FDC2 _ .SRD",  the  user 

would  type  the  following: 

"Copy  PDC2 _ .8RD  A:" 

In  the  above  example,  "A:"  refers  to  the 
destination  drive  (the  drive  to  which  the 
file  is  to  be  copied) . 


Deleting  CRDS  data  files 

Deleting  data  files  from  the  CRDS  files  directory 
must  be  accomplished  from  the  DOS  environment.  To 
delete  data  files,  complete  the  following  steps. 

1.  First  exit  the  CRDS  by  pressing  the  <E8C>  key 
repeatedly.  If  the  CRDS  data  file  has  not 
recently  been  saved,  a  warning  message  will 
appear.  Upon  exiting  the  CRDS  program,  the 
prompt  "C:\CRD"  will  be  displayed, 
indicating  that  the  user  is  in  the  "C:\CRD" 
directory  of  the  DOS  environment. 

2.  Entering  the  DOS  command  "Dir"  causes  all 
CRDS  files  to  be  listed.  All  files  that 
contain  CRDS  templates  or  data  files  are 
unique  because  of  their  ".SRD"  extension 
names.  If  the  guidance  of  the  previous 
subsections  has  been  followed,  there  will  be 

one  data  file  named  "FDC _ .SRD"  and 

another  named  "FDC2 _ .SRD".  Assume  that 

the  duplicate  file  is  to  be  deleted. 
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3.  Entering  the  DOS  command  "del"  or  "erase” 
followed  by  the  complete  file  name  of  the 
data  file  and  pressing  <Return>  will  cause 
that  data  file  to  be  eliminated.  Using  the 
above  example,  to  delete  the  file 

"FDC2 _ .SRD",  the  user  would  type  "Del" 

followed  by  a  space  and  then  the  complete 
file  name,  as  shown  below. 

"Del  FDC2  . SRD" 


Pressing  <Return>  causes  the  named  file  to  be 
deleted  from  the  file  directory. 


PART  FOUR  -  BUILDING  A  CRDS  DATA  FILE 


overview 


Part  Four  of  the  User's  Guide  addresses  procedures 
to  be  followed  for  building  a  CRDS  data  file,  also 
called  a  crew  template.  As  described  in  Part  Two  of 
this  guide,  a  crew  template  is  comprised  of  the 
information  required  to  describe  precisely  the 
composition  and  structure  of  a  crew.  The  CRDS  assists 
the  user  in  building  the  template  through  the 
presentation  of  highly  formatted  data  input  screens. 
After  an  overview  of  the  types  of  data  input  required 
and  of  constraints  on  the  order  of  entering  the  data, 
this  part  of  the  User’s  Guide  will  provide  detailed 
descriptions  on  how  to  build  a  template. 

To  facilitate  the  user's  understanding  of  these 
instructions,  the  user  will  be  asked  to  enter  the  data 
required  to  define  an  example  of  a  template  for  the 
crew  of  a  prototype  weapon  system.  Instructions  that 
specifically  address  the  building  of  this  template  will 
be  presented  separately  from  the  more  general 
descriptions  on  how  to  build  a  template.  These 
specific  instructions  are  indented  and,  as  mentioned 
previously,  the  prompted  input  appears  in  bold  type. 

Required  Data  Input 

As  introduced  in  Part  Three  of  this  guide,  the 
user  builds  a  model  of  a  crew  by  entering  data  into  the 
preformatted  files  of  the  "BUILD  TEMPLATE  OPTIONS" 
menu.  This  menu,  illustrated  in  Figure  6,  is  accessed 
from  the  CRDS  "MAIN  OPTIONS"  menu. 


BUILD  TEMPLATE  OPTIONS  - 

ENTER  RESOURCES/ITEMS 

ENTER  TASKS 

ASSIGN  RESOURCES  TO  TASKS 
ASSIGN  TASK  RELATIONS 

ENTER  PERFORMANCE  MEASURES 
SELECT  ACTIVE  TASK  MEASURE 

ESC 

1 _ 

Figure  6.  The  CRDS  Build  Template 
Options  Menu. 
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As  may  be  seen  in  Figure  6,  there  are  six  options  in 
the  "BUILD  TEMPLATE  OPTIONS"  menu  that  address  the 
input  of  six  different  types  of  data  and  one  option  for 
escaping  from  the  "BUILD  TEMPLATE  OPTIONS"  menu  to 
return  to  the  CRDS  "MAIN  OPTIONS"  menu.  To  build  a 
complete  template,  each  of  the  six  data  input  options 
of  the  "BUILD  TEMPLATES  OPTIONS"  menu  must  be  selected 
and  completed.  After  each  menu  option  has  been 
selected  for  data  input,  an  arrow  will  appear  next  to 
that  menu  option. 

By  way  of  preview,  the  data  input  required  for 
each  of  the  menu  items  is  described  in  succeeding 
paragraphs . 

•  Resources /items:  Enter  the  number  and  names 
of  the  different  types  of  crew  members  that 
are  available  and  assigned  to  perform  the 
tasks  required  by  the  mission  of  the  crew. 

•  Tasks :  Enter  the  nvimber  and  names  of  the 
different  tasks  that  must  be  performed  if  the 
crew  is  to  accomplish  its  mission. 

•  ^  .sign  Resources  to  Tasks:  Enter  the  numbers 
and  the  names  of  types  of  crew  members 
assigned  to  perform  each  unique  task. 

•  Assign  Task  Relations:  Enter  the  names  of 
all  tasks  whose  performance  must  be  completed 
before  performance  on  a  currently  identified 
task  can  begin. 

•  Performance  Measures;  Enter  the  time 
required  for  each  crew  member  to  perform  each 
task  to  which  they  have  been  assigned. 

•  Select  Active  Task  Performance  Time  Measure; 
If  two  sets  of  performance  time  measures  have 
been  entere 1,  the  user  must  specify  which  one 
is  to  be  used  during  a  particular  run  of  the 
CRDS. 


Reguired  Order  for  Data  Entry 

The  user  must  first  enter  the  numbers  and  names  of 
the  different  types  of  crew  members  and  the  different 
tasks  that  need  to  be  performed,  though  the  order  of 
entering  these  two  template  parameters  is  not  relevant. 
The  number  of  different  types  of  crew  members  and  the 
number  of  tasks  which  must  be  performed  are  necessary 
and  sufficient  to  create  and  to  save  a  CRDS  data  file. 
Secondly,  the  user  can  enter  information  necessary  to 
assign  task  relations  and  to  assign  types  of  crew 
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members  to  tasks,  but  there  is  no  prescribed  or 
preferred  order  for  entering  these  two  template 
parameters.  Finally,  the  user  would  enter  task 
performance  time  data. 


Succeeding  sections  of  this  part  of  the  User's 
Guide  will  provide  detailed  instructions  for  responding 
to  each  of  the  options  in  the  "BUILD  TEMPLATE  OPTIONS" 
menu,  in  the  order  in  which  they  occur  and  are 
illustrated  in  Figure  6.  In  the  process  of  working 
though  these  sections,  the  user  will  build  a  template 
for  the  crew  of  a  prototype  gun  system. 


Enter  Resources/Item  Information 

The  "ENTER  RESOURCES/ ITEMS"  option  of  the  "BUILD 
TEMPLATE  OPTIONS"  menu  prompts  the  user  to  specify  the 
number  of  different  types  of  crew  members  required  to 
perform  mission  essential  tasks  and  then  to  provide  the 
names  for  each  type  of  crew  member. 

When  defining  this  parameter  of  a  template,  it  is 
most  common  to  refer  to  either  the  title  of  the  duty 
position  or  to  the  military  occupational  specialty 
(MOS)  and  the  associated  grade  or  skill  level  of  each 
type  of  crew  member. 

To  enter  crew  member  information,  the  following 
actions  need  to  be  taken. 


1.  Select  "ENTER  RESOURCES/ ITEMS"  from  the 

"BUILD  TEMPLATE  OPTIONS"  menu.  The  screen 
displayed  in  Figure  7  will  appear  prompting 
the  user  to  enter  the  number  of  different 
types  of  crew  members. 


1 - ! 

ENTER  NUMBER  OF  RESOURCES  IN  THIS  TEMPLATE 

>  3 

PRESS  RETURN  TO  CONTINUE 

1 _ 1 

Figure  7 .  Screen  allowing  desired  number 
of  resources  to  be  entered. 


To  build  the  template  for  the 
prototype  gun,  the  user  should  enter  "3" 
and  press  <Return>. 
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2.  After  entering  the  required  number  of 

different  types  of  crew  member  and  pressing 
<Return>,  the  box  illustrated  in  Figure  8 
will  be  displayed  to  prompt  the  user  to  enter 
the  name  of  the  first  type  of  crew  member. 
(The  maximum  length  of  the  name  of  a  crew 
member  is  10  alphanumeric  characters.) 


ENTER  NAME  OF  RESOURCE  NUMBER  01 
>  SQUAD  LDR 

PRESS  RETURN  TO  CONTINUE 


Figure  8.  Screen  prompting  resource  name. 


3 .  After  entering  a  name  for  each  type  of  crew 
member  and  pressing  <Return>,  the  screen 
shown  in  Figure  8  will  be  redisplayed  to 
prompt  the  user  to  enter  the  name  for  the 
next  (successively  higher  numbered)  type  of 
crew  member. 

4.  After  entering  the  name  of  the  final  type  of 
crew  member,  the  next  press  of  the  <Return> 
key  will  redisplay  the  "BUILD  TEMPLATE 
OPTIONS"  menu  illustrated  in  Figure  6.  There 
will  be  an  arrow  next  to  the  "ENTER 
RESOURCES/ ITEMS"  option,  indicating  that 
input  to  that  option  has  been  provided. 


To  build  the  template  for  the 
prototype  gun,  the  user  should  enter  the 
following  names  for  the  types  of  crew 
members  as  their  numbers  are  prompted. 


Promoted 

Resource  ( Crew 

Resource  ( Crew 

Member)  Name 

Member)  Number 

Inout 

11]^  II 

"Squad  Ldr" 

112" 

"Gunner" 

II 3 II 

"Loader" 

IMPORTAMT:  At  the  present  stage  of  development,  CRDS 
does  not  allow  the  user  to  edit  input  to  the  "EMTER 
RESOURCES/ITEMS"  option  after  it  has  been  entered.  If 
this  option  is  reentered  for  the  purpose  of  editing. 
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tbe  prompt  for  the  number  of  resources  in  the  template 
will  not  reappear  and  changes  made  to  resource  or  crew 
member  names  will  not  be  reflected  in  any  of  the 
subsequent  screens  or  printouts.  If  an  incorrect  entry 
is  made,  the  user  must  exit  the  system  and  reinitiate 
the  procedure  for  building  template. 

MOTE:  Normally,  each  different  type  of  crew  member 
will  be  given  its  otm  unique  name.  However,  there  may 
be  occasions  in  which  more  than  one  instance  of  a 
particular  type  of  crew  member  may  be  needed  to 
accomplish  a  mission  in  a  timely  manner.  For  exeunple, 
several  indistinguishable  lower  ranking  soldiers  may  be 
necessary  to  provide  general  support  to  the  fire 
mission  of  a  howitzer  crew.  Once  the  precise  roles  of 
these  multiple  instances  of  a  type  of  crew  member  have 
been  clearly  differentiated  and  defined,  they  should  be 
given  unique  identities  in  the  crew  template,  e.g.. 
Crewmember  l  and  Crewmember  2. 


Enter  Tasks 


The  procedure  for  defining  the  mission  essential 
tasks  of  the  crew  is  similar  to  that  for  defining  types 
of  crew  members.  To  enter  information  on  the  tasks  the 
crew  is  recpiired  to  perform,  the  following  actions  need 
to  be  taken. 

1.  Select  the  "ENTER  TASKS"  option  of  the  "BUILD 
TEMPLATE  OPTIONS"  menu.  Figure  9  will  appear 
prompting  the  user  to  enter  the  number  of 
tasks. 


ENTER  NUMBER  OF  TASKS  IN  THIS  TEMPLATE 


>  8 _ 

PRESS  RETURN  TO  CONTINUE 


Figure  9.  Screen  prompting  desired  number  of 
tasks. 


To  build  the  template  for  the 
weapon  called  gun,  the  user  should  enter 
"8"  and  press  <Return>  to  indicate  that 
the  mission  of  the  crew  requires  the 
performance  of  eight  tasks. 

Important:  The  number  of  required  tasks  cannot  be 
edited  once  the  value  has  been  entered  and  the  <Return> 
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Key  pressed.  If  an  incorrect  entry  is  made,  the  user 
must  exit  CRDS,  without  saving  the  data  file,  and  start 
the  data  file  building  procedure  again. 

2.  After  defining  the  number  of  tasks, 

pressing  <Return>  causes  the  box  shown  in 
Figure  10  to  be  displayed.  This  screen 
prompts  the  user  for  the  name  of  the  first 
task  (10  character  spaces  maximum) . 


To  continue  building  the  template 
for  the  prototype  gun,  the  user  should 
enter  "Attend  Sen”  (for  attend  to  the 
scanner)  as  the  name  for  the  first 
mission  task. 


Enter  task  01  nome  with  a  maximum  of  10  characters 
>  Attend  Sen 

PRESS  RETURN  TO  CONTINUE 


Figure  10.  Box  prompting  short  task  name. 


3.  After  entering  the  name  of  the  first  task, 
pressing  <Return>  causes  the  box  shown  in 
Figure  11  to  be  displayed.  This  screen 
prompts  the  user  to  enter  a  longer  version  of 
the  task  name  or  a  comment  on  the  short  name 
just  entered. 


Enter  long  name  for  task 
PRESS  RETURN  TO  CONTINUE 


Figure  ll.  Screen  prompting  long  task 

name. 


NOTE:  Due  to  an  error  in  the  present  version  of  CRDS, 
while  the  long  names  or  comments  for  tasks  can  be 
entered,  they  cannot  be  later  retrieved,  either  on  the 
screen  or  in  printouts.  Therefore,  there  is  no  need 
for  inserting  any  information  in  these  "long  name" 
screens.  Instead,  press  <Return>  each  time  the  prompt 
for  long  task  names  appears. 
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To  continue  building  the  template 
for  the  gun,  the  user  should  enter  the 
following  task  names  as  each  task  number 
is  prompted. 

Promoted 
Task  Number 

Task  Name 

Inout 

•12" 

"Ann  Tgt” 

••311 

"Fire  Ord" 

tt4tt 

"Aim  Gun" 

II 5  « 

"Fire  Gun" 

"6" 

"Load  Gun" 

ii'^ii 

"Check  Chbr" 

iigii 

"Unload  Gun" 

4,  When  the  last  of  the  predesignated  tasks  have 
been  named,  pressing  the  <Return>  key  will 
return  the  user  to  the  "BUILD  TEMPLATE 
OPTIONS"  menu.  There  will  be  an  arrow  next 
to  the  "ENTER  TASKS"  option,  indicating  that 
input  has  been  provided  to  this  option. 

NOTE:  Each  different  task  should  be  given  its  own 
unique  name.  This  is  particularly  important  because  a 
task  network  must  be  developed  and  a  type  of  crew 
member  assigned  to  perform  each  task.  In  some  cases, 
the  mission  of  the  crew  may  be  to  perform  a  specific 
task  repeatedly.  For  example,  launch  (or  load) 
multiple  but  identical  missiles  from  (or  on  to)  a 
missile  launcher,  in  these  cases,  the  user  should  use 
unique  task  names  to  differentiate  among  instances  of 
the  otherwise  identical  tasks,  e.g.,  Firel,  Fire2,  etc. 


Editing  Task  Name  Entries 

The  CRDS  allows  task  names  to  be  edited.  To  edit 
these  entries,  reselect  "ENTER  TASKS"  from  the  "BUILD 
TEMPLATE  OPTIONS"  menu  and  press  the  <Return>  key. 
Pressing  <Return>  will  make  the  short  task  names  appear 
in  the  order  in  which  they  were  entered.  Continue 
pressing  the  <Return>  key  until  the  task  name  to  be 
edited  appears.  Press  the  space  bar  to  delete  that 
task  name,  and  enter  the  new  task  name.  Pressing 
<Retum>  only  allows  the  user  to  move  forward  through 
the  task  list.  If  the  user  accidentally  moves  past  the 
task  name  that  is  to  be  changed,  it  will  be  necessary 
to  move  the  end  of  the  task  list  and  start  again. 
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Saving  Your  Work 

The  user  can  save  the  template  that  has  been  thus 
far  developed.  To  do  so,  access  the  "FILES"  option  of 
the  "MAIN  OPTIONS"  menu.  Then  access  the  "SAVE 
TEMPLATE  TO  DISK"  option  and  enter  the  desired  data 
file  name.  The  user  should  consider  saving  the 
template  or  partially  built  template  after  any 
significant  amount  of  data  input.  By  doing  so,  the 
user  can  avoid  losing  the  entire  file  should  there  be 
an  accidental  exit  from  the  system. 

To  save  the  partially  built 
template  for  the  prototype  gun,  the  user 
should  access  the  "SAVE  TEMPLATE  TO 
DISK"  option  and  enter  the  name 
"Example"  for  the  filename  when  prompted 
to  do  so. 


Assign  Resources  to  Tasks 

Having  specified  both  the  required  tasks  of  the 
crew  and  the  types  of  resources  or  crew  members,  the 
user  can  designate  which  type  of  crew  member  will 
perform  each  task.  To  do  so  the  user  should  select  the 
"ASSIGN  RESOURCES  TO  TASKS"  option  of  the  "BUILD 
TEMPLATE  OPTIONS"  menu.  A  screen  similar  to  that  shown 
in  Figure  12  will  be  displayed. 

This  screen  permits  the  user  to  specify 
information  needed  to  allocate  crew  members  to  tasks. 
These  items  of  information  are  features  of  the  sentence 
which  is  displayed  within  the  rectangle  shown  near  the 
bottom  of  the  screen: 

"There  are  *  number  of  Resource  ^  assigned  to  Task  _1_." 

Using  this  screen,  the  user  specifies:  (a)  how  many 
of  (b)  each  particular  type  of  crew  member  will  be 
assigned  to  perform  (c)  each  required  crew  task. 

By  entering  the  values  assigned  to  various 
combinations  of  these  three  items  of  information,  the 
user  specifies  the  allocation  of  crew  members  to  tasks. 
The  steps  which  cause  these  allocations  are  described 
in  succeeding  paragraphs. 


1.  To  specify  the  name  of  the  task,  which  will 
appear  in  the  top  and  bottom  lines  of  the 
screen  as  well  as  at  the  right  end  of  the 
rectangle,  the  user  presses  the  <Ctrl-Arrow> 
keys  (i.e.,  the  <Ctrl>  and  <Left-  or  Right- 
Arroir>  keys  pressed  simultaneously)  . 
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RESOURCES  AVAILABLE  TO  BE  ASSIGNED  TO  TASK  Ch«ck  Chbr 
SQUAD  LOR  GUNNER  LOADER 


Th«re  or*  01  numbar  of  R«»ourc«  LOADER  osalqiKd  lo  Tosk _ Ch«ck  Chbr 

RESOURCES  ASSIGNED  TO  TASK  Check  Chbr 


Figure  12.  Screen  allowing  assignment  of  resources 
to  tasks. 


2.  To  assign  a  particular  type  of  crew  member 
to  perform  the  designated  task,  the  user 
presses  the  arrow  keys  ( i . e . ,  the  <  Right- 
Arrow>  or  <Left-Arrow>)  to  highlight  the  name 
of  that  type  of  crew  member  in  the  list  which 
is  displayed  near  the  top  of  the  screen  and 
to  display  that  name  in  the  center  of  the 
rectangle. 

3.  To  increase  or  decrease  the  value  of  the 
number  shown  at  the  left-end  of  the  rectangle 
to  indicate  how  many  of  the  identified  type 
of  crew  member  are  required  to  perform  the 
designated  task,  the  user  presses  the  plus 
(<+>)  or  minus  (<->)  keys,  respectively. 

NOTE:  More  than  one  instance  of  a  particular  type  of 
crew  member  may  be  assigned  to  perform  a  given  task, 
e.g./  two  identically  classified  mechanics  may  be 
assigned  to  perform  the  task  of  removing  a  heavy  item 
of  equipment  from  the  engine  compartment  of  a  vehicle. 
Likewise,  more  than  one  type  of  crew  member  may  be 
assigned  to  perform  a  given  task,  e.g.,  a  military 
police  service  member  and  a  military  intelligence 
service  member  may  both  be  assigned  to  the  task  of 
interrogating  an  enemy  prisoner  of  war.  An 
illustration  of  both  of  the  examples  given  above  would 
be  one  gunner  and  two  loaders  assigned  to  the  task  of 
rearming  a  weapon  platform. 

4.  The  user  repeats  each  of  Steps  1,  2,  and  3 
until  all  assignments  are  completed. 

5.  When  all  assignments  are  completed,  the  user 
presses  the  <Esc>  key  to  quit  the  "ASSIGN 
RESOURCES  TO  TASKS"  option  and  return  to  the 
"BUILD  TEMPLATE  OPTIONS"  menu.  This  menu 
will  show  an  arrow  to  the  left  of  the  "ASSIGN 
RESOURCES  TO  TASKS"  Option  to  indicate  that 
this  option  has  been  addressed  by  the  user. 
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To  continue  building  the  template 
of  the  prototype  gun,  the  user  should 
make  the  follow  assignment  of  types  of 
crew  members  to  tasks: 


Number 

of 

Tvoe  of 
Crew  Member 

Assigned 
to  Task 

fl^fl 

"Squad  Ldr" 

"Attend  Sen" 

nj.** 

"Squad  Ldr" 

"Ann  Tgt" 

n^ti 

"Squad  Ldr" 

"Fire  Ord" 

It  ^11 

"Gunner" 

"Aim  Gun" 

II 

"Gunner" 

"Fire  Gun" 

II  ^11 

"Loader" 

"Load  Gun" 

It  ^11 

"Loader" 

"Check  Chbr" 

II  ^11 

"Loader" 

"Unload  Gun" 

Editing  Allocation  of  Resources  to  Tasks 

The  user  should  re-access  the  "ASSIGN  RESOURCES  TO 
TASKS"  option  and  repeatedly  press  the  <Ctrl-Arrow>  and 
the  <Arrow>  keys  to  examine  the  entries  that  have  been 
made,  checking  them  for  their  accuracies.  If  a  change 
is  desired  in  any  previous  assignment  it  can  be  made  by 
following  the  instructions  given  in  Steps  1  through  3 
above  for  that  particular  data  input. 

Saving  Your  Work 

The  user  can  save  the  template  that  has  been  thus 
far  developed.  To  do  so,  access  the  "FILES"  option  of 
the  "MAIN  OPTIONS"  menu.  Then  access  the  "SAVE 
TEMPLATE  TO  DISK"  option  and  enter  the  desired  data 
file  name. 

To  save  the  partially  built 
template  for  the  gun,  the  user  should 
access  the  "SAVE  TEMPLATE  TO  DISK" 
option  and  enter  the  name  "Example"  for 
the  filename  when  prompted  to  do  so. 


Assign  Task  Relations 

The  "ASSIGN  TASK  RELATIONS"  option  Of  the  "BUILD 
TEMPLATE  OPTIONS"  menu  is  used  to  specify  any  required 
order  in  which  mission  essential  tasks  must  be 
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performed.  The  only  prerequisite  for  providing  this 
information  is  that  the  tasks  themselves  must  first  be 
specified  in  the  "ASSIGN  TASKS"  option. 

Selecting  "ASSIGN  TASK  RELATIONS"  will  display  the 
screen  displayed  in  Figure  13 .  This  screen  shows  at 
the  top  of  the  screen  a  list  of  all  the  previously 
specified  tasks.  Inside  the  rectangular  box  near  the 
bottom  of  the  screen  is  shown  the  name  of  a  task  whose 
predecessor  is  currently  under  consideration  and  a 
number  designating  its  serial  position  in  the  order  in 


CANDIDATES  TO  PRECEDE  TASK 

Attend  Sen  Ann.  Tgt  Fire  Ord  Fire  Gun  Load  gun 
Check  Chbr  Unload  Gun 


I  Current  Task  Name  Check  Chbr  and  Number  07 

TASKS  TO  PRECEDE  CURRENT  TASK 
Fire  Gun 


Figure  13.  Screen  allowing  task  relations  to  be 
established. 


which  the  task  names  were  entered.  The  user  designates 
which  of  the  previously  specified  tasks  are 
"predecessor"  tasks  whose  performance  must  be  completed 
before  the  performance  of  the  "current"  task  can  be 
initiated.  To  designate  tasks  as  predecessors,  the 
following  steps  need  to  be  taken. 

1.  Press  the  <Ctrl-Arroir>  keys  as  necessary  to 
change  the  task  appearing  in  the  rectangle. 

2.  Tasks  which  are  predecessors  to  the  task 
shown  in  the  rectangle  are  designated  by 
pressing  the  <Arroif>  keys.  Pressing  the 
<Arroir>  keys  moves  the  reverse  video  bar  over 
the  list  of  candidate  predecessor  tasks. 

3.  When  a  desired  predecessor  task  has  been 
highlighted  (covered  by  the  reverse  video) , 
press  <Returix>  to  establish  that  task  as  a 
predecessor  for  the  task  shown  in  the 
rectangle.  The  selected  predecessor  task 
will  be  displayed  below  the  rectangular  box. 
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NOTE:  The  "ASSIGN  TASK  RELATIONS"  procedure  will  not 
allow  assignments  that  will  create  cycles.  A  cycle 
occurs  when  two  tasks  either  are  defined  as  directly  or 
indirectly  preceding  each  other,  thus  creating  a 
circular  path.  The  CRDS  will  not  display  an  error 
message  if  the  user  attempts  to  assign  a  circular  path. 
Instead,  the  task  will  simply  not  appear  below  the 
rectangular  box. 

4.  Repeat  Steps  1  through  3  until  all  required 
task  relationships  have  been  established. 

5.  After  all  required  predecessor  tasks  been 
entered,  press  <Ese>  to  return  to  the  "BUILD 
TEMPLATE  OPTION"  menu.  An  arrow  next  to 
"ASSIGN  TASK  RELATIONS"  option  indicates  that 
information  has  been  entered  for  this  option. 

NOTE:  This  set  of  data  will  be  determined  by  a  large 
number  of  factors,  to  include  equipment  constraints 
(e.g.,  a  gun  must  be  loaded  before  it  can  be  fired)  and 
operational  constraints  (e.g.,  a  target  must  be 
positively  identified  as  a  threat  before  it  can  be 
engaged) .  The  performance  of  a  given  task  may  have  to 
await  the  completion  of  more  than  one  predecessor  task 
and  the  performance  of  more  than  one  task  may  be 
initiated  simultaneously  after  the  performance  of  a 
given  predecessor  task  is  completed. 


To  continue  building  the  template 
for  the  gun,  the  user  should  select 
"ASSIGN  TASK  RELATIONS",  and  enter  the 


following  input: 

Current  Task 
(in  rectangle) 

"Attend  Sen" 

"Ann  Tgt" 

"Fire  Ord" 

"Aim  Gun" 

"Fire  Gun" 

"Load  Gun" 
"Check  Chbr" 
"Unload  Gun" 


Predecessor  Task 
(highlight) 

[None] 

[None] 

"Ann  Tgt" 

"Pire  Ord" 

"Load  Gun"  and 
"Aim  Gun" 

[None] 

"Pire  Gun" 

"Pire  Gun" 
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i  remainder  of  this  section  on  assigning  task 
relations  may  be  skipped  if  the  reader  is  not 
interested  in  a  rationale  for  the  task  relations 
assigned  in  the  example  template. 

1.  The  mission  scenario  begins  with  the  Squad  Leader 
viewing  a  scanner.  Therefore,  "Attend  Sen"  has  no 
necessary  predecessor. 

2.  Viewing  the  scanner  and  announcing  a  target 
are  tasks  which  may  be  performed  concurrently. 
However,  the  Squad  Leader  may  identify  a  target 
without  viewing  the  scanner.  Therefore,  "Attend 
Sen"  is  not  listed  as  a  necessary  predecessor  for 
"Ann  Tgt". 

3.  "Fire  Ord"  has  "Ann  Tgt"  as  a  necessary 
predecessor  because  a  target  must  be  announced 
before  the  Squad  Leader  can  order  the  Gunner  to 
engage  it. 

4.  It  is  assumed  that  the  Gunner  will  not  aim  the  gun 
at  a  target  unless  and  until  the  Squad  Leader 
issues  a  fire  order.  (Note  that  this  set  of  task 
relationships  will  allow  the  Gunner  to  aim  an 
unloaded  gun.) 

5.  In  order  for  the  gun  to  be  fired,  it  must  have 
been  loaded  and  aimed.  Therefore,  "Fire  gun"  has 
both  "Aim  Gun"  and  "Load  Gun"  as  required 
predecessors . 

6.  For  this  example  mission,  "Load  Gun"  has  no 
necessazy  predecessors.  In  a  combat  mission, 
weapons  would  generally  be  loaded  prior  to 
beginning  an  operation. 

7.  The  ex2uaple  template  presumes  that  the  firing 
chamber  is  checked  whenever  the  gun  has  been 
fired.  The  "Check  Chbr"  task  therefore  has  "Fire 
Gun"  as  a  necessary  predecessor. 

8.  For  this  example  template,  the  gun  must  be  fired 
before  an  empty  shell  casing  can  be  removed. 
Therefore,  "Fire  Gun"  is  listed  as  a  necessary 
predecessor  for  "Unload  Gun". 

In  order  to  determine  the  critical  path,  the  CRDS 
requires  only  that  the  predecessors  immediately 
preceding  the  task  currently  under  consideration  be 
entered.  For  example,  in  the  template  of  the  gun  crew, 
even  though  the  performance  of  a  number  of  tasks  may  be 
required  before  the  task  of  "Unload  Gun"  may  be 
performed,  the  task  "Fire  Gun"  is  the  last  required 
predecessor.  Therefore,  it  is  sufficient  to  only  enter 
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"Fire  Gun”  to  esteiblish  all  the  tasks  which  must 
precede  the  performance  of  “Unload  Gun".  In  fact,  as 
defined,  "Unload  Gun"  must  be  preceded  by  "Fire  Gun", 
which  must  be  preceded  by  "Aim  Gun"  and  "Load  Gun" .  In 
turn,  "Aim  Gun"  must  be  preceded  by  the  task  sequence 
of  "Attend  Sen",  "Ann  Tgt",  and  "Fire  Ord".  The  only 
one  of  the  eight  tasks  which  is  not  a  required 
predecessor  to  "Unload  Gun"  is  "Check  Chbr",  and  it 
might  be  presumed  that  the  latter  task  is  performed 
concurrently  with  unloading  the  empty  shell  casing. 

Editing  Task  Sequence  Information 

Task  secjuence  can  be  edited  at  any  time.  Simply 
reenter  the  "ASSIGN  TASK  RELATIONS"  option  of  the 
"BUILD  TEMPLATE  OPTIONS"  menu.  The  screen  illustrated 
in  Figure  13  will  be  redisplayed. 

To  delete  (or  un-assign)  a  task  as  a  necessary 
predecessor,  press  the  <PgDn>  key.  This  moves  the 
reverse  video  bar  to  the  bottom  of  the  screen  thereby 
allowing  a  previously  selected  task  to  be  highlighted. 
Press  the  <Arroir>  keys  to  highlight  one  of  the 
previously  selected  predecessor  tasks  and  then  press 
<Ratum>  to  delete  that  task.  The  deleted  task  will  no 
longer  be  listed  as  a  necessary  predecessor  of  the  task 
appearing  in  the  rectangle. 

Pressing  the  <PgUp>  key  will  return  the  video  bar 
to  the  list  of  candidate  predecessor  tasks  at  the  top 
of  the  screen.  Pressing  <B80>  will  return  the  display 
to  the  "BUILD  TEMPLATES  OPTIONS"  menu. 

Saving  Your  Work 

As  previously  described,  the  user  can  and 
generally  should  access  the  "FILES"  option  to  save  the 
template  that  has  been  thus  far  developed. 


Enter  Perfomanoe  Measures 

The  "ENTER  PERFORMANCE  MEASURES"  option  allows  the 
user  to  specify  the  time  required  to  perform  each  task 
defined  for  the  template.  Before  using  this  option  the 
user  must  have  completed  all  of  the  options  which 
precede  it  in  the  "BUILD  TEMPLATE  OPTIONS"  menu,  i.e., 
"ENTER  RESOURCES/ ITEMS",  "ENTER  TASKS",  "ASSIGN 
RESOURCES  TO  TASKS",  and  "ASSIGN  TASK  RELATIONS." 

The  procedure  for  entering  individual  task 
durations  is  outlined  below. 

1.  Select  the  "ENTER  PERFORMANCE  MEASURES" 

option  of  the  "BUILD  TEMPLATE  OPTIONS"  menu. 
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The  box  illustrated  in  Figure  14  will  be 
displayed,  prompting  the  user  to  input  for 
the  number  of  alternative  sets  of  performance 
measures  that  are  to  be  entered.  The  CRDS 
allows  the  user  to  enter  either  one  or  two 
sets  of  task  performance  time  estimates  for  a 
single  data  file.  For  example,  this  option 
enables  the  user  to  enter  task  durations  for 
two  sets  of  mission  conditions  (e.g.,  rested 
and  fatigued  crews)  or  for  two  alternative 
equipment  configurations . 

NOTE:  Due  to  an  error  in  the  present  version  of  the 
CRDS,  while  two  sets  of  task  performance  time  data  may 
be  entered,  only  the  first  set  entered  can  be  reliably 
retrieved  for  inclusion  into  a  template.  Therefore, 
the  user  is  encouraged  to  enter  only  one  set  of 
performance  time  data  for  each  data  file.  Alternate 
sets  of  performance  time  data  may  be  entered  into 
copies  of  the  original  template. 


Enter  Number  of  Performance  Measures 
(Integer  Between  1—2]  2 

Press  Return  When  Done  Entering 


Figure  14.  Screen  allowing  desired  nvimber  of 
performance  measures  to  be  entered. 


2.  Enter  the  desired  number  of  performance 
measures  into  the  screen  illustrated  in 
Figure  14  and  press  <Retum>.  Another 
screen,  illustrated  in  Figure  15,  will  appear 
prompting  the  user  for  the  name  of  the 
(first)  performance  measure. 


Enter  Name  for  Performance  Measure  1 
Time  1 

Name  must  be  10  Chars  or  Less 


Figure  15.  Box  prompting  the  name  of  the 
first  set  of  estimates. 
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3 .  Enter  the  name  of  the  performance  measure 
into  the  space  provided  and  press  <Return>. 
Another  display  will  be  added  to  that 
illustrated  in  Figure  15,  prompting  the  user 
to  define  the  unit  of  measure  for  the  named 
measure.  This  new  display  is  illustrated  in 
Figure  16. 

4.  Enter  the  time  unit  of  the  defined  task 
performance  measure.  The  user  could  enter 


Enter  Name  for  Performance  Measure  1 

_ Time  1 _ 

Name  must  be  10  Chars  or  Less 


Enter  Units  for  this  Measure 
Seconds _ 

Enter  Type  of  Units  for  this  Measure 
(ex.  inches,  seconds,  hours,  dollars) 

Press  Return  When  Done  Entering 


Figure  16.  Screen  allowing  time  unit  to  be 
entered. 


minutes,  seconds,  or  fractions  of  time  units 
as  appropriate.  For  example,  1/2-second  or 
two-second  intervals  could  be  used. 

IMPORTANT:  Even  though  non-temporal  performance 
measures  are  listed  as  options,  at  this  stage  of  its 
development,  the  CRDS  is  equipped  to  process  only 
temporal  measures  of  performance. 

5.  If  the  user  has  indicated  in  Step  2  that  two 
measures  of  performance  were  to  be  entered, 
the  next  two  presses  of  the  <Retum>  key  will 
redisplay  the  prompts  illustrated  in  Figures 
15  and  16,  prompting  for  the  name  of  the 
second  set  of  time  measures  and  the  name  of 
the  second  set  of  time  units,  respectively. 

NOTE:  The  CRDS  provides  no  editing  capability  for  the 
above  inputs  to  the  »ENTER  PERFORMANCE  MEASURES" 
option.  However,  as  the  above  inputs  consists  of 
labels  for  the  performance  time  measures,  the 
consequences  of  making  an  incorrect  entry  are  not  very 
serious.  The  task  durations  themselves  can  be  edited, 
as  described  below. 
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After  the  information  called  for  in  Steps  l 
through  5  has  been  entered,  pressing  <Return> 
will  display  a  screen  similar  to  that 
illustrated  in  Figure  17.  This  screen 
prompts  the  user  to  enter  the  performance 
duration  for  each  task,  beginning  with  the 
first  task  entered  in  the  "ENTER  TASK"  option 
of  the  "BUILD  TEMPLATE  OPTIONS"  menu.  Each 
time  a  task  duration  is  entered,  pressing  the 
<Return>  key  will  cause  the  screen  to 
reappear,  prompting  the  estimated  duration  of 
the  next  task  in  the  sequence.  Figure  17  is 


\ 


TASK:  Attand  Sen 
RSCRCE:  Squad  Ldr 


MEASURE:  Tlinal 
•RSRCES:  000 1 


Entar  Number  of  Units  Seconds 
needed  to  perform  thie  taak  4:00 

Press  Return  When  Done  Entering 


Figure  17 .  Screen  prompting  estimated  task 
duration. 


labelled  to  show  the  locations  on  the  screen 
of  the  following  information: 

A.  Name  of  the  task  to  be  assigned  a 
performance  measure. 

B.  Name  of  the  type  of  crew  member 
assigned  to  perform  the  task. 

C.  Name  of  the  performance  time 
measure  (see  NOTE  on  page  45) . 

D.  Required  number  of  the  indicated 
type  of  crew  member. 

E.  The  performance  time  of  the 
indicated  type  of  crew  member  ( in 
the  time  units  previously 
specified) . 

The  CRDS  provides  information  for  locations 
labelled  A  through  D  in  Figure  17;  the  user 
must  provide  the  actual  performance  time 
measure  in  the  space  labelled  E. 
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7.  Once  all  the  performance  time  measures  have 

been  entered,  press  <Retum>  to  return  to  the 
"BUILD  TEMPLATE"  options  menu. 

To  continue  building  the  example 
template,  the  user  should  enter  the 
following  performance  time  measures. 

(The  measure,  named  Timel,  is  in  units 
of  "seconds") . 

Promoted  Input  To  Timel 

Task  Name 

Attend  Sen 
Ann  Tgt 
Fire  Ord 
Aim  Gun 
Fire  Gun 
Load  Gun 
Check  Chbr 
Unload  Gun 

Editing  Performance  Measures 

To  edit  performance  measures,  re-select  the  "ENTER 
PERFORMANCE  MEASURES"  option  of  the  "BUILD  TEMPLATE 
OPTIONS"  menu.  The  screen  illustrated  in  Figure  17 
will  be  presented  for  the  first  task  defined.  If 
necessary,  the  user  can  enter  any  corrections  to  the 
performance  time  measure  for  this  task.  Repeatedly 
pressing  the  <Retum>  key  causes  the  CRDS  to  display 
the  data  screen  appropriate  for  each  task  in 
succession.  Pressing  the  <Ese>  key  will  abort  the 
editing  at  any  time  and  return  the  user  to  the  "BUILD 
TEMPLATE  OPTIONS"  menu. 


Select  Active  Task  Measure 

If  two  sets  of  task  performance  time  measures  have 
been  entered,  the  user  must  specify  which  one  is  to  be 
used  for  a  subsequent  analysis  of  the  template  created. 
The  default  and  normally  only  active  task  measure  is 
the  first  set  of  measures  entered  (see  NOTE  on  Page 
41). 

To  select  the  active  task  measure,  perform  the 
following  steps. 

1.  Select  the  "SELECT  ACTIVE  TASK  MEASURE" 
option  of  the  "BUILD  TEMPLATE  OPTIONS"  menu. 

2.  Enter  the  number  of  the  task  performance  time 
measure  that  is  to  be  used  in  the  subsequent 
analysis  and  press  <Retuni>  to  return  to  the 
"BUILD  TEMPLATE  OPTIONS"  menu. 


"6.0" 

"2.0" 

"1.0" 

"3.0" 

"1.0" 

"4.0" 

"3.0" 

"4.0" 
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Introduction 


After  the  data  required  to  build  a  CRDS  template 
have  been  entered,  the  user  can  examine  and  analyze 
that  template  using  any  of  the  various  tal.uiar  and 
graphic  representations  provided  by  the  CRDS  of  those 
data.  The  user  can  also  obtain  printouts  of  CRDS 
information.  These  include  both  the  input  to  the 
CRDS  -  the  information  entered  through  the  BUILD 
TEMPLATE  OPTIONS  -  and  the  CRDS  output  -  the  graphic 
and  tabular  summaries  of  the  template  data  files. 
However,  before  this  information  becomes  available, 
either  on  the  monitor  screen  or  in  print,  the  user  must 
first  calculate  the  critical  path. 


Calculating  the  Critical  Path 

The  CRDS  automatically  calculates  the  critical 
path  based  upon  the  performance  times  of  tasks  and  the 
contingencies  among  tasks.  To  calculate  the  critical 
path,  select  the  "CALCULATE  CRITICAL  PATH"  option  from 
the  "MAIN  OPTIONS"  menu.  Once  an  arrow  is  displayed  to 
the  left  of  this  option,  as  illustrated  in  Figure  18, 
the  critical  path  has  been  calculated.  The  user  can 
now  access  the  various  representations  of  the  template 
data,  either  on  the  monitor  screen  or  in  hard  copy. 


MAIN  OPTIONS 


FILES 

BUILD  TEMPLATE 
CALCULATE  CRITICAL  PATH 
DISPLAY  PERT/GANTT 
PRINT  OPTIONS 
ESC 


Figure  18.  CRDS  Main  Menu  with  critical 
path  calculated. 


The  CRDS  Print  CapzUsility 

As  mentioned  previously,  calculating  the  critical 
path  enables  the  user  to  print  CRDS  data.  These  data 
consist  of  both  the  input  provided  by  the  user  when 
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building  the  template,  and  also  the  various 
representations  and  summaries  of  the  crew  data  file 
provided  by  the  CRDS.  The  procedure  for  printing 
summaries  of  the  CRDS  input  will  be  discussed  first. 

IMPORTANT  NOTE:  To  successfully  obtain  printouts  of 
information  associated  with  a  CRDS  data  file,  the 
current  version  of  the  CRDS  software  requires  that  the 
resident  personal  computer  be  directly  connected 
through  its  parallel  output  port  to  a  dedicated  Epson- 
compatible  printer.  Laser  printers  are  not  compatible 
with  the  CRDS  software  and  will  not  print  graphic  and 
tabular  outputs  of  the  CRDS. 


Printing  CRDS  Input 

In  order  to  obtain  printouts  of  the  information 
entered  through  the  "BUILD  TEMPLATE  OPTIONS"  menu,  the 
user  must  select  "PRINT  OPTIONS"  from  the  CRDS  "MAIN 
OPTIONS"  menu.  A  PRINT  MENU,  illustrated  in  Figure  19, 


TASK  LABELS 

REQUIRED  NUMBER  PER  TASK 

DUTY  PSN  OR  ITEM  LABEL 

REQUIRED  PREDECESSOR  EVENTS 

DUTY  POSITION  OR  ITEM  PERFORMABILITY 

PRINT  ALL 

ESC 


Figure  19.  CRDS  Files  Options  Menu 


will  be  displayed.  If  selected,  the  options  of  this 
menu  will  cause  the  following  information  to  be 
printed. 

"TASK  LABELS"  -  The  (short)  names  of  mission 
essential  tasks. 

"REQUIRED  NUMBER  PER  TASK"  -  The  number  and  names 
of  each  type  of  crew  member  assigned  to 
perform  each  task. 

"DUTY  PSN  OR  ITEM  LABEL"  -  The  names  of  the  types 
of  crew  members  assigned  to  the  crew. 

"REQUIRED  PREDECESSOR  EVENTS"  -  The  names  of  all 
predecessor  tasks  for  each  required  task. 

"REQUIRED  SUCCESSOR  EVENTS"  -  The  names  of  all 
successor  tasks  for  each  required  task. 
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"DUTY  POSITION  OR  ITEM  PERFORMABILITY"  -  The 

performance  time  data  for  each  required  task, 
listed  separately  for  each  type  of  crew 
member . 

"PRINT  ALL"  -  Each  of  the  six  input  data  sets 
described  above. 


Printing  CRDS  Output 

Calculating  the  critical  path  also  allows  the  user 
to  print  copies  of  the  tabular  and  graphic  output 
provided  by  the  CRDS.  Two  different  procedures  are 
available  to  print  most  types  of  CRDS  output.  To  print 
any  CRDS  output,  display  that  output  on  the  monitor 
screen  (the  procedures  for  displaying  the  various 
output  are  discussed  in  the  next  section)  and  press  the 
<Print  8creen>  key  (the  <Prt  so  key  on  some  systems) . 
This  key  press  will  cause  only  that  part  of  the  output 
displayed  on  the  monitor  screen  to  be  printed. 

Some  CRDS  output  may  be  printed  by  displaying  the 
output  of  interest  on  the  monitor  screen  and  pressing 
the  "P”  key.  When  this  method  is  applicable,  a  prompt 
or  instruction  to  enter  "P"  to  obtain  a  printout  is 
displayed  beneath  the  output  on  the  monitor  screen. 

When  this  procedure  is  available  and  selected,  all  of 
the  designated  CRDS  output  data  will  be  printed,  even 
if  it  is  not  all  displayed  on  the  monitor  screen. 


Accessing  CRDS  Output 

Calculating  the  critical  path  is  necessary  in 
order  for  the  user  to  view  the  various  types  of  CRDS 
outputs.  These  outputs  can  be  used  to  examine  and 
analyze  the  template  and,  if  judged  desirable,  to 
search  for  and  create  alternative  crew  designs.  The 
creation  of  an  alternative  crew  design  is  accomplished 
by  modifying  the  data  which  define  the  crew  template. 
Procedures  for  moc’lfying  a  crew  template  are  described 
in  Part  Six  of  this  User's  Guide.  The  remainder  of 
this  part  of  the  guide  will  describe  how  to  access  each 
of  the  output  formats  and  the  types  of  information 
available  when  each  one  is  selected  for  viewing. 

To  view  the  different  representations  of  CRDS 
output,  select  the  "DISPLAY  PERT/GANTT"  option  of  the 
"MAIN  OPTIONS"  menu.  This  action  will  display  the  menu 
illustrated  in  Figure  20.  This  T.enu  is  not  labelled 
when  displayed  on  the  screen.  However,  because  it  is 
accessed  by  selecting  the  "DISPLAY  PERT/GANTT"  option 
of  the  "MAIN  OPTIONS"  menu,  it  will  be  referred  to  in 
this  User's  Guide  as  the  "PERT/GANTT  options"  menu. 
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Resource  Loading 
See  critical  Task 
Conflict  Adjustment 
GANTT  Timelines 
Deconfliction  Analysis 
Conflict  Overlap 

— ►  Calculate  Critical  Path 

PERT  Diagram 
ESC 


Figure  20.  PERT/GANTT  Options  Menu. 


The  descriptions  of  the  CRDS  outputs  that  follow 
will  use  the  data  file  created  when  the  template  named 
"Example"  was  built  following  the  instructions  given  in 
Part  Four  of  this  User's  Guide.  Consequently,  if  the 
user  has  exited  the  CRDS  since  building  and  saving  this 
template  built  for  the  crew  of  a  prototype  gun  system, 
the  user  should  read  this  file  from  the  CRDS  directory 
before  continuing. 

Since  the  GANTT  chairt  presents  the  template 
timeline  information  in  an  especially  useful  graphical 
format,  it  will  be  discussed  first. 


GANTT  Timelines 


Instructions  for  Accessing  the  "GANTT  Timelines"  Potion 

To  access  the  GANTT  chart,  the  following  actions 
need  to  be  performed. 

1.  Select  the  "GANTT  Timelines"  option  from  the 
PERT/GANTT  options  menu.  Doing  so  causes  the 
menu  illustrated  in  Figure  21  to  be 
displayed.  This  latter  menu  lists  the  two 
GANTT  display  options  offered  by  the  CRDS: 

(a)  a  display  of  the  task  timeline  for  all 
types  of  crew  members  together  in  one  GANTT 
chart,  and  (b)  a  display  of  the  timeline 
attributable  to  one  specified  type  of  crew 
member.  The  GANTT  chart  presenting  the 
timeline  for  all  types  of  crew  members  will 
be  described  first. 

2 .  Select  "Display  GANTT"  from  the  menu 
illustrated  in  Figure  21  to  display  the  GANTT 
chart  for  the  template  named  "Example."  This 
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GANTT  Chart  is  illustrated  in  Figure  22.  The 
various  features  of  the  GANTT  chart  will  be 
described  in  the  next  subsection. 


Display  GANTT 
Select  Resource 
ESC 


Figure  21.  GANTT  Chart  Options 
Menu. 


Features  of  the  GANTT  Timeline  Chart 

e  The  GANTT  timeline  is  a  graphic  representation 

of  the  schedule  of  start  and  stop  times  for  each 
task  performed  during  a  crew's  mission.  If  the 
mission  duration  is  less  than  20  seconds,  the  task 
timeline  is  divided  into  single-second  intervals. 
If  mission  duration  is  20  seconds  or  longer,  the 
total  mission  duration  will  be  divided  into  ten 
equal  timeline  intervals. 

•  Each  task  timeline  is  represented  by  a  task  name 
and  by  a  line  segment  proportional  in  length  to 
the  duration  of  that  task. 


Figure  22.  GANTT  timeline  chart  for  all  types  of  crew 
members  in  the  template  named  "Example." 
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•  Repeated  presses  of  the  (plus)  key  makes  the 

GANTT  chart  smaller.  Conversely,  repeated  presses 
of  the  (minus  or  hyphen)  key  makes  the  GANTT 

chart  larger.  If  the  GANTT  chart  is  too  large  to 
fit  on  the  monitor  screen,  pressing  the  arrow  keys 
displays  different  portions  of  the  GANTT  chart. 

NOTE:  It  is  worth  repeating  that  the  print  capability 
for  a  GANTT  chart  (the  <Print  8creen>  key)  will  print 
only  that  portion  of  the  chart  which  is  displayed. 

e  Each  task  on  the  critical  path  is  presented  with 
an  asterisk  preceding  the  task  name. 

e  The  sequence  of  numbers  following  each  task  name 
refers,  in  order,  to  the  start,  duration,  stop, 
and  slack  time  of  the  task.  For  critical  tasks, 
the  last  value  will  always  be  zero. 

s  The  number  at  the  top  of  a  GANTT  chart  which 

displays  the  tasks  performed  by  all  types  of  crew 
members  refers  to  the  stop  time  of  the  last  task 
to  be  completed.  This  number  is  also  the  total 
duration  of  the  mission. 

The  GANTT  chart  can  be  used  to  observe  and 
identify  tasks  whose  performance  overlap  in  time.  When 
two  or  more  tasks  performed  by  the  same  type  of  crew 
member  overlap  on  the  GANTT  timeline,  they  may 
represent  a  conflict  which  the  user  will  want  to 
resolve  through  some  modification  in  the  parameters  of 
the  template. 

The  information  in  the  GANTT  chart  for  each  type 
of  crew  member  is  also  available,  in  a  less  cluttered 
and  perhaps  more  useful  form,  in  separate  GANTT  charts 
for  each  individual  type  of  crew  member.  To  view  GANTT 
charts  for  a  specific  type  of  crew  member.  Press  <Bsc> 
to  return  to  the  menu  for  the  GANTT  chart  (shown  in 
Figure  21) .  Select  the  "Select  Resource"  option  to 
display  a  listing  of  the  names  of  types  of  crew 
members.  Selecting  one  of  the  names  and  pressing 
<Return>  will  display  the  GANTT  chart  displaying  only 
the  timelines  for  tasks  performed  by  that  type  of  crew 
member. 


To  continue  using  the  template 
named  "Example,"  select  "Squad  Ldr"  to 
display  the  GANTT  chart  for  squad 
leaders,  illustrated  in  Figure  23. 

It  may  be  seen  that  three  of  the  tasks  assigned  to 
the  crew  member  named  Squad  Ldr,  i.e.,  the  tasks  named 
"Ann  Tgt,"  "Attend  Sen,"  and  "Fire  Ord,"  are  performed 
in  overlapping  time  intervals. 
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Figure  23.  GANTT  timeline  for  tasks  performed  by  the 
crew  member  type  named  "Squad  Ldr." 

The  requirement  to  perform  multiple  tasks 
concurrently  could  overload  this  type  of  crew  member. 

To  illustrate,  the  tasks  shown  as  being  performed 
simultaneously  could  demand  concurrent  and  incompatible 
responses  of  this  type  of  crew  member  (e.g.,  that  the 
squad  leader  look  in  opposite  directions  at  the  seime 
time) ,  or  they  could  demand  that  different  tasks  be 
performed  concurrently  at  different  physical  locations 
with  respect  to  the  weapon  system  (e.g.,  perform  one 
task  while  the  squad  leader  is  to  the  left  and  another 
while  the  squad  leader  is  to  the  right  of  the  gun 
barrel) .  This  overload  in  task  demands  on  one  squad 
leader  could  cause  the  performance  of  one  or  more 
tasks,  and  hence  the  performance  of  the  total  mission, 
to  deteriorate.  We  will  return  to  this  discussion  in 
Part  Six  to  illustrate  how  to  modify  templates. 

It  should  also  be  noted  that  the  number  displayed 
at  vthe  top  of  a  GANTT  chart  showing  only  the  tasks 
performed  by  a  selected  type  of  crew  member  refers  to 
the  total  svim  of  all  task  performance  times  for  the 
designated  crew  member.  In  Figure  23,  this  total 
performance  time  is  shown  to  be  nine  seconds,  even 
though,  because  of  the  overlap  in  task  performance,  all 
three  tasks  are  completed  in  only  six  seconds.  Using 
these  numbers,  the  user  can  determine  the  distribution 
of  workload  over  the  different  types  of  crew  members. 
For  the  template  "Example,"  it  can  be  shown  that  during 
a  mission  whose  total  duration  is  11  seconds,  the  squad 
leader,  gunner,  and  loader  are  assigned  tasks  whose 
performances  requires  nine,  four,  and  eleven  seconds, 
respectively . 
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As  mentioned  previously,  the  GANTT  chart  provides 
a  timeline  representation  of  the  crew's  mission.  This 
representation  also  labels  critical  tasks  and  indicates 
which  required  tasks  overlap  with  other  tasks  and  thus 
represent  possible  conflicts.  Consequent  i-y.  the  GANTT 
chart  contains  all  of  the  information  pre-orted  by  the 
other  options  in  the  PERT/GANTT  options  mena.  The 
other  options,  however,  convey  this  information  in  a 
number  of  useful  formats,  each  of  which  will  be 
discussed  in  subsequent  sections  of  this  part  of  the 
User's  Guide. 


Resource  Loading 

IMPORTANT  NOTE:  Due  to  an  error  in  the  present  version 
of  the  CRD8/  the  "Resource  Loading"  option  is  not 
working  properly  and  therefore  does  not  produce 
reliable  results,  it  is  recommended  that  this  option 
not  be  used.  Since  the  information  that  was  to  be 
summarised  in  the  resource  loading  spreadsheet  is  also 
available  in  several  alternate  formats,  not  using  the 
"Resource  Loading"  option  will  not  adversely  affect  the 
user's  ability  to  analyse  and  create  alternative  crew 
templates. 


See  Critical  Task 

Selecting  the  "See  Critical  Task"  option  of  the 
PERT/GANTT  options  menu  causes  the  screen  illustrated 
in  Figure  24  to  be  displayed.  This  screen  lists  the 


Cr i t i CO  1  T osk  Sequence 


Task 

Start 

Stop 

Duration 

2 
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TGT 

2.0 

2.0 

3 

FIRE 

ORD 

2.0 

3.0 

1.0 

4 

AIM 

GUN 

3.0 

B.O 

3.0 

5 

FIRE 

GUN 

B.O 

7.0 

1.0 

8 

UNLOAD 

GUN 

7.0 

11.0 

4.0 

Figure  24.  Screen  showing  critical  task  path. 


number  and  neune  of  each  task  that  is  on  the  critical 
path,  in  the  order  in  which  it  is  performed.  In 
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three  colvunns  following  the  number  and  name  of  each 
critical  task  is  its  start  time,  completion  or  stop 
time,  and  duration,  respectively.  The  list  of  critical 
tasks  is  useful  both  in  determining  what  types  of 
modifications  can  be  made  to  the  crew  template  and  in 
assessing  the  consequences  of  these  changes. 


Conflict  Adjustment 

Selecting  the  "Conflict  Adjustment"  option  of  the 
PERT/GANTT  options  menu  will  display  the  table 
illustrated  in  Figure  25.  This  table  lists  the  name  of 
each  task  whose  performance  overlaps  in  time  that  of 
other  tasks  performed  by  the  same  type  of  crew  member. 
Assuming  that  the  overlap  in  task  performances 
represents  a  conflict,  the  table  also  provides 
information  on  how  the  conflict  can  be  resolved  by 
delaying  the  start  time  of  the  designated  task. 


DECONFLICTION 

FREQUBCIES 

WITHIN 

ACCS 

ADD  ALL 

AOO  PART 

ADD  PART 

TASK 

MSN  TlbC 

MSN  TIKE 

MIITHIN 

VI  THIN 

TO  MS^ 

Attend  Sen 

2 

Q 

2.0 

0.0 

0.0 

Ann  Tgt 

0 

1 

0.0 

0.0 

6.0 

Omet  atr 

0 

1 

0.0 

1.0 

3.0 

unload  Gun 

0 

1 

0.0 

0.0 

3.0 

Figure  25. 

Table 

depicting 

task 

overlap . 

The  table  illustrated  in  Figure  25  is  labelled 

"DECONFLICTION  FREQUENCIES,"  and  has  six  columns. 

•  Column  1,  labelled  "TASK,"  lists  the  names  of  the 
tasks  in  conflict  with  other  tasks  performed  by 
the  same  type  of  crew  member. 

•  Colinnn  2,  labeled  "WITHIN  MSN  TIME,"  identifies 
the  number  of  times  the  designated  task  is  in 
conflict  with  other  tasks  and  a  delay  in  the 
designated  task  can  resolve  the  conflict  without 
adding  to  total  mission  time.  It  should  be 
apparent  to  the  user  that  only  non-critical  tasks 
will  have  a  non-zero  entry  in  this  column. 

•  Column  3,  labelled  "ADDS  MSN  TIME,"  identifies 
the  niimber  of  times  the  designated  task  is  in 
conflict  with  other  tasks  and  a  delay  in  the 
designated  task  can  resolve  the  conflict  but  only 


53 


PART  FIVE  —  VIEWING  AND  PRINTING  CRDS  OUTPUT 


bv  adding  to  total  mission  time.  The  tasks  which 
have  non-zero  entries  in  this  column  are  critical 
tasks,  i.e.,  tasks  on  the  critical  path. 

•  Column  4,  labelled  **ADD  ALL  WITHIN”  shows  the 
minimum  delay  in  the  start  time  required  to  remove 
at  least  one  of  the  conflicts  identified  in  Column 

2  for  a  designated  non-critical  task. 

•  Columns  5  and  6,  taken  together,  identify  the 
minimum  delay  in  the  start  time  required  to  remove 
at  least  one  of  the  conflicts  identified  in  Column 

3  for  a  designated  critical  tasks.  Column  5, 
labelled  "ADD  PART  WITHIN,"  shows  the  portion  of 
the  required  delay  in  start  time  that  would  not 
affect  total  mission  time.  Column  6,  labelled 
"ADD  PART  TO  MSN,"  shows  the  portion  of  the 
required  delay  that  would  add  to  mission  time. 

The  data  contained  in  the  table  illustrated  in 
Figure  25  provide  much  information  of  general  value  to 
the  user  who  wishes  to  understand  detailed  features  of 
the  template  under  study.  However,  this  information  is 
of  possibly  greatest  value  when  the  user  is  searching 
for  ways  to  remove  conflicts  in  the  performance  of 
tasks  assigned  to  a  particular  type  of  crew  member. 
Consequently,  a  further  description  of  this  information 
is  contained  in  the  next  part  of  this  User's  Guide. 


Deconflict ion  Analysis 

The  "Deconfliction  Analysis"  option  of  the 
PERT/GANTT  options  menu  is  the  one  the  user  may  select 
in  order  to  make  modifications  to  a  template  data  file. 
The  modifications  would  be  introduced  to  resolve  or 
eliminate  a  conflict  in  task  performance.  A 
description  of  the  information  and  the  additional 
options  it  provides  to  the  user  is  the  basis  for  the 
material  presented  in  Part  Six  of  this  User's  Guide. 


Conflict  overlap 

If  the  user  selects  the  "Conflict  Overlap"  option 
of  the  PERT/GANTT  options  menu,  the  CRDS  presents  a 
table  of  detailed  information  on  each  pair  of  tasks 
whose  performance  times  overlap  for  each  type  of  crew 
member.  That  table,  labelled  "Simultaneous  Resource 
Request,"  is  illustrated  in  Figure  26.  For  the 
template  named  "Example,"  the  table  provides  data  on 
the  two  pairs  of  tasks  whose  performance  overlap  for 
the  crew  member  "SQUAD  LDR, "  and  the  one  pair  of  tasks 
whose  performance  overlaps  for  the  crew  member 
"LOADER." 
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Figure  26.  Screen  representing  simultaneous  task 
requirements . 


In  all  three  cases,  the  table  identifies  the  type 
of  crew  member  that  is  required  to  simultaneously 
perform  two  tasks,  the  nvunbers  and  names  of  the  two 
tasks,  their  respective  start,  stop,  and  slack  time  (if 
any) ,  and  the  amount  of  overlap  in  the  performance 
times  of  the  two  tasks.  As  can  be  seen  in  Figure  26, 
tasks  on  the  critical  path,  i.e.,  tasks  with  zero  slack 
time,  are  labelled  "CRITICAL"  in  the  table. 

The  information  contained  in  the  table  accessed 
though  the  "Conflict  Overlap"  option  is  particularly 
useful  for  deciding  which  tasks  are  candidates  for 
delayed  starting  times  or  for  reassignment  to  alternate 
types  of  crew  members. 


Calculate  Critical  Path 

This  option  of  the  PERT/GANTT  options  menu  is 
provided  to  permit  the  user  to  recalculate  the  critical 
path  after  a  modification  to  the  template  data  file. 

It  would  be  used  in  conjunction  with  the  "Deconfliction 
Analysis"  option  and,  hence,  is  i  levant  to  the 
discussion  of  that  option  given  in  Part  Seven  of  this 
User's  Guide. 


PERT  Diagram 


A  PERT  diagram  is  a  network  representation  of  a 
crew  template.  It  graphically  shows  the  sequencing  of 
tasks  and  highlights  the  sequence  of  tasks  which  is  the 
critical  path  sequence. 

NOTE:  One  of  the  chief  strengths  of  the  PERT  diagram 
is  its  modifiability.  As  will  become  evident,  there 
are  many  ways  to  represent  template  data  in  a  PERT 
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diagram.  The  CRDS  facilitates  the  creation  of  these 
alternative  portrayals  but  the  user  must  be  prepared  to 
invest  time  in  generating  the  PERT  diagram  that  is  most 
useful  for  the  problem  at  hand.  Fortunately,  the  CRDS 
file  saving  capability  allows  the  user  to  save  these 
modifications,  essentially  creating  a  library  of 
alternate  versions  of  the  PERT  diagram. 

To  access  the  CRDS  routine  which  aids  the  user  in 
designing  a  PERT  diagram  and  to  subsequently  display 
and  print  the  diagram  that  is  developed,  the  user 
selects  the  "PERT  Diagram"  option  of  the  PERT/ GANTT 
options  menu.  Doing  so  causes  the  menu  illustrated  in 
Figure  27  to  be  displayed.  This  menu  lists  the  two 
PERT  diagram  display  options  offered  by  the  CRDS: 

(a)  display  all  the  tasks  performed  by  all  types  of 
crew  members  together  in  one  PERT  diagram,  and  (b) 
display  only  the  tasks  performed  by  one  specified  type 
of  crew  member. 


Display  Pert 
Select  Resource 
Esc 


Figure  27.  Menu  of  PERT 
options . 

The  user  should  initially  select  the  first  option, 
"Display  PERT",  in  order  to  design  a  PERT  diagram  that 
portrays  the  task  network  in  a  meaningful  manner. 

Doing  so  for  the  template  named  "Example"  causes  the 
CRDS  to  draw  the  initial  PERT  diagram  for  that 
template.  This  initial,  CRDS -generated  PERT  diagram  is 
illustrated  in  Figure  28.  The  features  of  this  PERT 
diagram  are  described  in  the  next  subsection. 

Features  of  the  Initial  CRDS -Generated  PERT  Diagram 

•  As  mentioned  previously,  the  PERT  diagram  is 

a  network  representation  of  the  crew  mission.  In 
this  representation,  tasks  are  represented  as 
lines;  the  start  and  finish  points  of  these  tasks 
are  represented  as  nodes  at  the  beginning  and  end 
of  the  task  lines.  Task  lines  are  labelled  with 
their  respective  task  names. 

•  Tasks  are  connected  to  other  tasks  by  "dummy 
tasks,"  lines  labeled  with  a  "d"  or  "t"  in  Figure 
28.  Dummy  tasks  connect  the  finish  points  of  each 
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mission  essential  task  with  the  start  points  of 
required  successor  tasks  in  the  task  network.  If 
a  task  is  followed  by  more  than  one  required 
successor  task,  its  finish  point  will  have  a  dummy 
task  line  connecting  it  to  the  start  of  each  of 
those  required  successor  tasks.  If  a  task  does 
not  have  a  required  successor  task,  a  dummy  task 
line  connects  the  finish  point  of  that  task  with 
the  node  representing  the  end  or  completion  of  the 
mission. 


Figure  28.  The  initial  PERT  diagram  generated  by  the 
CRDS. 


e  The  lines  representing  critical  tasks,  i.e., 

,  tasks  in  the  critical  path,  are  drawn  in  the  PERT 
diagram  with  a  bolder  and  thicker  line. 

e  If  a  PERT  diagram  is  too  large  to  fit  on  the 

monitor  screen,  repeated  presses  of  the  "+"  (plus) 
key  will  make  the  diagram  smaller.  Conversely, 
repeated  presses  of  the  (minus  or  hyphen)  key 
will  cause  the  diagram  to  be  larger  in  size,  if 
the  diagram  is  too  large  to  fit  on  the  monitor 
screen,  pressing  the  arrow  keys  will  cause 
different  portions  of  the  diagram  to  be  displayed. 
The  user  should  note  that  employing  the  CRDS  print 
option  that  uses  the  <Print  8creen>  key  will 
produce  a  hard  copy  of  only  that  portion  of  a  PERT 
diagram  which  is  displayed  on  the  monitor  screen. 

The  user  will  generally  wish  to  're-draw'  the 
initial  CRDS -generated  PERT  diagram.  Even  the 
relatively  simple  diagram  illustrated  in  Figure  28 
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for  the  template  named  "Example”  is  visually 
cluttered  and  hence  not  as  informative  as  it  could 
be.  Procedures  for  changing  the  visual  appearance 
of  the  PERT  diagram  are  described  below. 


Using  the  Mouse  to  Modify  a  PERT  Diagram 

As  already  mentioned,  a  major  strength  of  the  CRDS 
PERT  diagram  is  its  modifiability.  The  CRDS  offers  the 
user  a  procedure  for  editing  a  PERT  diagram,  both 
initially  and  again  as  the  user  progressively  modifies 
and  updates  the  data  file  of  a  template. 

This  redrawing  capability  is  accomplished  using 
the  mouse,  which,  if  properly  installed  in  the  computer 
system,  is  enabled  whenever  the  "PERT  Diagram"  option 
is  selected. 

The  mouse  allows  the  user  to  make  the  task  network 
represented  by  the  PERT  diagram  appear  any  way  the  user 
desires.  If  the  user  wishes  to  change  the  location  of 
a  node  in  the  diagram,  the  (normally)  arrow-shaped 
cursor  associated  with  the  left  button  on  the  mouse  is 
placed  over  the  location  of  that  node.  Then,  pressing 
and  holding  down  the  left  button  allows  the  user  to 
move  the  node  anywhere  on  the  screen.  Figure  29 
illustrates  how  the  diagram  shown  in  Figure  28  can  be 
redrawn  by  moving  the  location  of  just  one  node,  the 
node  which  represents  the  end  of  the  task  named  "Ann 
Tgt."  Figure  30  presents  the  results  of  our  attempt  to 
draw  an  uncluttered  and  more  readable  and  useful  PERT 
diagram  for  the  template  named  "Example." 


Figure  29.  PERT  diagram  with  a  single  node  altered. 
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Figure  30.  PERT  diagram  modified  to  increase  its 
readability  and  usability. 

NOTE:  In  Figure  30  some  of  the  dumny  lines  have  hidden 
•hidden*  by  making  the  node  representing  the  finish 
point  of  one  task  congruent  with  the  node  representing 
the  start  point  of  a  successor  task.  We  have  retained 
the  dummy  task  lines  only  for  those  cases  in  which  a 
task  did  not  have  a  required  successor  task. 

It  must  be  emphasized  that  the  PERT  diagrams 
illustrated  in  Figures  28  through  30  are  useful  only 
for  showing  the  sequential  relationships  among  tasks 
during  the  performance  of  some  specified  mission;  they 
illustrate  the  presence  and  absence  of  any  necessary 
predecessor  or  successor  tasks.  These  diagrams  do  not 
automatically  display  any  functions  that  relate  to  the 
performance  times  of  individual  tasks  or  the  total 
mission.  Both  the  vertical  and  horizontal  placement  or 
location  of  nodes  and  the  lines  connecting  nodes,  as 
well  as  the  physical  lengths  of  the  lines,  are 
arbitrary  with  respect  to  task  and  mission  performance 
timelines. 

Viewing  PERT  Diagrams  for  Selected  Types  of  Crew  Members 

Once  the  user  has  edited  the  PERT  diagram  so  it  is 
relatively  uncluttered,  the  diagram  may  be  redrawn  to 
display  only  the  event  nodes  and  tasks  performed  by  one 
specified  type  of  crew  member.  To  select  the  PERT 
diagram  for  a  specific  type  of  crew  member,  press  <Eso> 
to  return  to  the  PERT  options  menu,  previously 
illustrated  in  Figure  27.  Then  select  the  "Select 
Resource"  option.  A  listing  of  the  names  of  the  types 
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of  crew  members  will  be  displayed.  Selecting  one  of 
these  names  will  display  the  PERT  diagram  for  only  that 
type  of  crew  member. 

At  any  point  while  developing  or  viewing  PERT 
diagrams,  repeated  pressing  of  the  <Esc>  key  will 
return  the  user  to  the  PERT/GANTT  options  menu.  The 
most  recent  shape  or  form  of  the  PERT  diagram  is 
automatically  saved  by  the  CRDS  whenever  the  user 
escaper  from  the  PERT  diagram  screen.  Hence,  the  user 
can  return  to  this  screen  to  examine  or  modify  the  PERT 
diagram  at  any  time  during  an  analysis  of  the  template 
under  study. 


The  Mouse-Driven  Potions  Menu  of  a  PERT  Diagram 

Pressing  the  right  button  of  the  mouse  while  a 
PERT  diagram  is  displayed  on  the  monitor  screen  will 
cause  a  new  menu  to  be  displayed  in  the  upper  left 
corner  of  the  display.  There  are  three  options  in  this 
menu,  any  one  of  which  can  be  selected  by  placing  the 
arrow  cursor  on  the  desired  option  and  pressing  the 
right  button  of  the  mouse.  The  consequences  of 
selecting  two  of  these  options  are  easily  described, 
but  the  third  requires  a  more  detailed  discussion  which 
will  be  given  in  the  next  section.  Brief  descriptions 
of  the  three  options  follow: 

•  "Quit"  -  Selecting  this  option  causes  the 
PERT  diagram  to  disappear  and  the  menu  of 
PERT  options  illustrated  in  Figure  27  to  be 
displayed.  Pressing  the  <Esc>  key  has  the 
same  effect. 

•  "Print"  -  Selecting  this  option  is  an 
alternative  method  for  causing  a  hard  copy  of 
the  PERT  diagram  to  be  printed.  Pressing  the 
<Prlnt  8creen>  key  has  the  same  effect. 

•  "Time"  -  Selecting  this  option  causes  an 
alternative  CRDS-generated  PERT  diagram  to  be 
displayed.  In  this  diagram,  the  horizontal 
axis  is  a  task  and  mission  performance 
timeline. 


Time-dependent  PERT  Diagram 

If  selected,  the  mouse-driven  option  labelled 
•Time'  will  causes  horizontal  distances  in  the  PERT 
diagram  to  represent  task  performance  time.  The  left 
edge  of  all  nodes  are  located  at  the  earliest  times 
that  the  task  represented  by  the  line  following  the 
node  may  begin.  Vertical  distance  still  has  no  meaning 
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in  terms  of  measurement  but  may  be  used  to  spread  out 
the  nodes  and  declutter  the  PERT  diagram.  As  was  true 
for  the  PERT  diagrams  shown  in  Figures  28  through  30, 
the  user  can  modify  the  visual  appearance  of  the 
timeline-based  PERT  diagram  and  would  most  likely  want 
to  redraw  the  CRDS -generated  diagram  that  is  initially 
displayed. 

The  modification  of  a  timeline-based  PERT  diagram 
is  accomplished  using  the  same  procedures  that  were 
described  earlier  for  redrawing  the  PERT  diagrams  that 
are  independent  of  task  and  mission  performance  time. 
However,  since  the  horizontal  locations  of  each  node  in 
the  timeline-based  PERT  diagram  is  constant,  the 
location  of  nodes  can  only  be  varied  in  the  vertical 
dimension.  Also,  since  each  node  represents  the 
earliest  possible  start  time  for  the  task  which  follows 
its  location  in  the  diagram,  there  is  no  task  line  for 
tasks  which  do  not  have  a  required  successor  task. 
Hence,  there  is  no  task  line  representing  the  last  task 
in  the  critical  path  sequence  (i.e.,  the  task  whose 
completion  marks  the  end  of  the  prescribed  mission) . 
There  is  also  no  dummy  task  lines  connecting  the  nodes 
representing  the  completion  of  noncritical  tasks  and 
the  completion  of  the  last  task  in  the  critical  path. 

A  sample  problem  which  uses  timeline-based  PERT 
diagrams  is  given  in  Part  Seven  of  this  User's  Guide. 

IMPORTANT:  Unlike  the  PERT  diagrams  that  are 
independent  of  task  performance  time,  modifications  the 
user  makes  to  redraw  an  initial  CRDS-generated 
timeline-based  PERT  diagrau  are  not  saved  for  later 
examination.  Hence,  a  bard  copy  of  the  user  redrawn 
timeline-based  PERT  diagram  should  be  printed  using  the 
<Print  Screen>  key  before  the  user  uses  the  <Esc>  key 
to  exit  this  option  of  the  mouse-driven  options  menu  or 
this  CRDS  run.  Also,  unlike  the  non-timeline-based 
PERT  diagram,  timeline-based  PERT  diagrams  cannot  be 
generated  for  only  selected  types  of  crew  members. 

NOTE:  It  should  be  stressed  again  that  while  the  PERT 
diagram  option  of  the  CRDS  allows  the  user  to  portray 
the  task  network  of  the  crew  in  a  very  graphic  and 
meaningful  manner,  it  does  not  contain  a  great  deal  of 
quantitative  information.  Also,  even  though  the  CRDS 
permits  it  to  be  drawn  in  a  semiautomatic  manner,  it 
may  require  a  great  deal  of  the  user's  time  and  energy 
to  redraw  it  to  the  user's  satisfaction.  Users  who 
wish  to  utilize  the  PERT  diagram  option  of  the  CRDS  are 
encouraged  to  explore  the  feature  at  their  convenience. 


Escape  <Esc> 

Selecting  this  option  of  the  PERT/GANT  options 
menu  transfers  the  user  to  the  CRDS  main  options  menu. 
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Introduction 


As  was  previously  discussed,  a  general  goal  of 
the  CRDS  is  to  enable  the  user  to  examine  alternative 
organizational  solutions  to  crew  workload  problems.  In 
this  regard,  an  examination  and  analysis  of  the  various 
graphic  and  tabular  representations  of  the  crew 
template  (as  described  in  Part  Five)  may  show  that  the 
initial  structure  and  organization  of  the  crew  has  some 
real  or  potential  workload  problems. 

An  overload  in  work  requirements  occurs  if  there 
is  too  much  demand  on  available  types  of  crew  members. 
This  would  be  the  case  if  there  were  a  requirement  for 
one  type  of  crew  meiober  to  simultaneously  perform  two 
or  more  incompatible  tasks.  If  this  situation  were 
allowed  to  exist,  one  of  two  consequences  is  likely  to 
occur:  (a)  if  possible,  a  crew  member  might  attempt  to 

simultaneously  perform  two  or  more  tasks  (increasing 
the  possibility  that  performance  quality  will  decline) , 
or  (b)  a  crew  member's  performance  of  one  or  more  tasks 
will  be  delayed  until  the  incompatible  task  has  been 
completed  (increasing  the  likelihood  that  the  mission 
completion  time  will  be  too  long) . 

Equally  undesirable  is  the  situation  in  which 
there  is  an  underload  in  work  requirements ,  i . e . ,  a 
situation  in  which  there  is  too  little  demand  on  a  crew 
member.  This  would  occur  if  there  were  long  periods  of 
time  during  which  a  particular  type  of  crew  member  had 
no  task  performance  requirements.  In  this  case,  there 
is  an  excessive  amount  of  unproductive  or  idle  time. 

The  most  obvious  solution  to  a  situation  in  which 
crew  members  are  overloaded  is  to  increase  the  number 
of  personnel  assigned  to  perform  required  tasks. 
However,  adding  crew  members  will  increase  the  costs 
associated  with  the  crew  and  may  be  incompatible  with 
size  and  mobility  constraints  of  the  crew.  Similarly, 
simply  shifting  tasks  from  an  overloaded  to  an 
underloaded  crew  member  may  also  be  inappropriate. 
Clearly,  not  all  crew  members  may  are  capable  of 
adequately  performing  all  required  tasks. 

To  aid  the  user  in  addressing  problems  associated 
with  either  overloading  or  underloading  different  types 
of  crew  members,  the  CRDS  permits  the  user  to  quickly 
develop  alternative  crew  designs  for  study  and 
analysis.  Three  different  but  complementary  techniques 
are  available  in  the  CRDS  to  aid  in  this  process. 
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•  Delay  task  start  time.  In  a  sense,  delaying 

the  performance  start  times  of  selected  tasks  can 
be  the  simplest  solution  to  either  an  overload  or 
underload  problem.  Changing  the  time  interval 
during  which  a  task  is  performed  may  remove  the 
simultaneous  task  demands  placed  on  a  crew  member. 
Since  the  same  crew  member  performs  the  task 
regardless  of  its  start  time,  the  user  needs  to 
consider  the  performance  capabilities  of  only  a 
single  type  of  crew  member. 

•  Alternate  assignment  of  tasks  to  types  of  crew 
members.  A  more  judicious  allocation  of  tasks  to 
different  types  of  crew  members  may  permit  the 
workload  to  be  shifted  from  an  overloaded  crew 
member  to  an  underloaded  crew  member.  However, 
using  this  approach  to  address  workload  problems 
associated  with  an  initial  crew  design  means  that 
the  user  must  also  consider  the  task  performance 
capabilities  of  alternative  types  of  crew  members. 
The  performance  capabilities  of  some  types  of  crew 
members  may  have  to  be  changed  to  meet  the 
performance  requirements  of  newly  assigned  tasks. 
This  may,  in  turn,  require  a  change  in  personnel 
selection  or  training  procedures  or  a  redesign  of 
some  features  of  an  equipment  item. 

•  Reassign  task  sequences.  Redefining  the  sequence 
in  which  required  tasks  are  performed  is  another 
approach  made  available  in  the  CRDS  for  addressing 
workload  problems.  However,  it  is  generally  the 
most  difficult  approach  to  implement  of  the  three 
techniques  described  in  this  User's  Guide.  This 
is  especially  true  late  in  the  development  of 
materiel  and  personnel  assets  and  of  tactics, 
techniques,  and  procedures.  Once  crew  assets  and 
operational  procedures  have  been  fully  developed, 
they  may  drive  the  required  sequence  of  task 
perfoirmance.  For  example,  standard  operational 
procedures  typically  dictate  that  a  potential 
target  must  be  positively  identified  as  hostile 
before  it  can  be  engaged. 

By  employing  any  one  of  the  three  techniques  just 
outlined  for  addressing  workload  problems  in  a  crew 
template,  the  user  may  introduce  other  important 
changes  to  the  template.  Changes  in  task  performance 
start  times,  in  the  allocation  of  tasks  to  types  of 
crew  members,  or  in  the  temporal  relationship  among 
tasks  may  change  the  critical  path  through  the  task 
network.  A  change  in  the  critical  path  will  not  only 
affect  which  tasks  are  defined  as  critical  (i.e.,  tasks 
with  no  slack  time  for  their  performance)  but  also  may 
increase  or  decrease  the  total  mission  performance 
time. 
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Successive  sections  of  this  part  of  the  User's 
Guide  will  describe  in  detail  how  each  of  the  three 
techniques  are  accessed  and  used  with  the  CRDS.  The 
first  two  (delaying  tasks  and  reassigning  tasks  to  crew 
members)  are  accessed  through  the  "Deconflict ion 
Analysis"  option  of  the  PERT/GANTT  options  menu.  The 
third  (reassigning  task  sequences)  is  accessed  through 
the  "ASSIGN  TASK  RELATIONS"  option  of  the  "BUILD 
TEMPLATES  OPTIONS"  menu. 

To  implement  each  of  the  approaches  described 
below,  the  user  should  first  ensure  that  the  template 
of  interest,  i.e.,  the  template  named  "Example,"  is  in 
the  system  memory. 

NOTE:  Thera  may  wall  ba  other  solutions  to  problems 
associated  with  the  over  and  under  utilization  of 
different  types  of  crew  members,  but  they  often  involve 
more  than  changes  in  organizational  composition  and 
structure.  Judicious  use  of  the  capabilities  of  the 
CRDS  may  suggest  some  of  these  non-organizational 
solutions  to  the  problem.  (See,  for  example,  the 
second  sample  problem  given  in  Part  Seven  of  this 
Dser<s  Guide.)  The  user  is  encouraged  to  explore  fully 
the  alternative  capabilities  of  the  CRDS  to  address 
crew  workload  and  performance  problems. 


Delay  Task 


To  access  and  use  the  delay  task  approach  for 
addressing  crew  workload  problems,  the  following 
actions  need  to  be  taken: 

1.  After  calculation  of  the  critical  path, 

access  the  PERT/GANTT  options  menu  and  select 
the  "DECONFLICTION  ANALYSIS"  option.  The 
"Deconfliction  Frequencies"  table, 
illustrated  in  Figure  31,  will  appear. 

(This  table  was  previously  described  in 
conjunction  with  Figure  25.) 

The  data  shown  in  this  table  can  be  used  to 
illustrate  the  value  of  the  task  delay 
option.  Consider  the  task  named  "Attend  Sen" 
shown  in  the  first  column  of  the  table.  The 
"2"  shown  in  the  second  coltimn  for  "Attend 
Sen"  indicates  that  it  overlaps  and,  hence, 
is  in  conflict  with  two  other  tasks.  The 
"2.0"  shown  in  the  fourth  column  indicates 
that  a  two-second  delay  in  the  start  time  of 
the  task  would  resolve  its  conflict  (i.e., 
would  "deconflict"  its  relationship)  with  at 
least  one  of  those  two  tasks.  The  placement 
of  the  indicated  two-second  delay  in  Column  4 
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of  the  table  shows  that  this  delay  in  start 
time  would  not  affect  overall  mission 
completion  time.  (Clearly,  the  "Attend  Sen" 
task  is  not  on  the  critical  path  and  it  has  a 
slack  time  of  at  least  two  seconds . ) 
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Now  consider  the  third  task  shown  in  the 
first  column  of  the  table,  the  task  named 
"Check  Chbr."  The  "1"  listed  in  the  third 
column  for  this  task  indicates  that  it 
overlaps  with  one  other  task.  As  shown  in 
the  table,  a  four-second  delay  in  the  start 
of  the  "Check  Chbr"  task  will  resolve  its 
conflict  with  the  other  task.  One  second  of 
that  delay  would  fall  within  the  initial 
total  mission  time  but  the  remaining  three 
seconds  would  add  to  the  total  mission 
duration. 

Assvune  that  the  user  decides  to  eliminate  the 
conflict  associated  with  the  task  of  checking 
the  gun  chamber  by  delaying  the  start  of  its 
performance  by  four  seconds. 

2.  Press  any  key  and  a  display  listing  the  crew 
tasks  will  appear.  This  display  prompts  the 
user  to  select  a  task  whose  conflict  with  at 
least  one  other  task  is  to  be  resolved  (or 
whose  relationship  with  another  task  is  to  be 
deconflicted) . 

3 .  Move  the  reverse  video  over  the  task  to  be 
delay'  and  press  <Retuni> .  For  this  example 
temp'  ,  select  task  "Check  Chbr"  and  press 
<Retuni.'.  A  menu  of  actions  the  user  can  use 
for  deconflicting  the  selected  task  will  be 
added  to  the  display.  The  format  of  the 
total  display  at  this  point  is  illustrated  in 
Figure  32. 

4.  Select  "Delay  Task"  from  the  "Deconfliction 
Features"  menu  and  press  <Return>.  This 
action  will  cause  the  screen  illustrated  in 
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1  .  1 

Enter  Value  to  Delay  Task 

4. 

PRESS  RETURN  TO  CONTINUE 

Figure  32.  Box  allowing  the  user  to 
specify  the  desired  delay  period. 


Figure  32  to  be  presented.  That  screen 
prompts  the  user  to  enter  the  number  of  time 
units  that  the  selected  task  is  to  be 
delayed. 


SELECT  TASKS  FOR  OECONFLICTION 

Attend  Sen  Ann  Tgt  Fire  Ord  Aim  Gun  Fire  gun  Load  Gun 
Check  Chbr  Unload  Gun 


—  Chooee  a  Deconfllctton  Feature  - 

Delo)^  Task 
Alternate  Aiiignment 
Deconfllctton  Freq 
Zero  Delayed  Starle 
Calculate  Critical  Path 
ESC 


Figure  33.  The  CRDS  "Deconfliction 
Features"  menu  and  unit  task  list. 


5.  Based  of  the  data  shown  is  Figure  31,  the 
user  should  enter  "4"  and  then  press  <Retum> 
to  indicate  that  the  start  of  the  designated 
task  "Check  Chbr"  is  to  be  delayed  by  four 
seconds.  This  action  redisplays  the 
"Deconfliction  Features"  menu  illustrated  in 
Figure  33. 

6.  The  user  should  now  select  the  "Calculate 
Critical  Path”  option  of  the  Deconfliction 
Features"  menu.  This  step  is  necessary 
whenever  changes  are  made  to  a  template. 

7.  Once  the  critical  path  is  recalculated,  it  is 
possible  to  examine  the  effects  of  the  delay 
that  has  been  entered.  To  do  this,  select 
the  "Deconfliction  Freq"  option.  A 
deconfliction  frequencies  table  such  as  that 
shown  in  Figure  31  will  again  appear.  If  the 
user  has  followed  the  preceding  instructions 
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for  the  template  named  "Example,”,  the  task 
"Check  Chbr"  will  no  longer  be  listed  as 
conflicting  with  other  tasks. 

Verification  of  this  result  can  be  obtained 
by  examining  the  features  of  this  template  in 
the  conflict  overlap  table  or  the  Gantt 
Chart.  The  Gantt  Chart,  illustrated  in 
Figure  34,  also  shows  that  the  total  mission 
performance  time  has  been  increased  from  11.0 
seconds  to  14.0  seconds. 


Figure  34.  GANTT  chart  with  the  task  "Check  Chbr" 
delayed  by  four  seconds. 


t 

NOTE:  While  the  deconfliction  frequencies  table  shows 
with  how  aany  other  tasks  a  designated  task  is  in 
conflict,  it  does  not  specify  what  those  other  tasks 
are  or  which  type  of  crew  nenber  is  assigned  to  perform 
the  conflicting  tasks.  For  the  example  template,  with 
only  eight  tasks  and  three  types  of  crew  members,  this 
may  not  be  a  problem;  the  user  can  easily  remember  all 
the  details  of  the  template  data  file.  However,  for 
more  structurally  complex  crew  designs  the  user  may 
need  to  refer  to  the  screens  which  show  the  GANTT 
timelines  charts  or  to  the  conflict  overlap  table. 

These  alternate  sources  of  template  information  are 
described  in  Part  Six  of  this  manual.  Better  still, 
the  user  may  wish  to  obtain  a  printout  of  those  screen 
displays,  and  use  the  hard  copy  of  the  screens  to 
assist  la  remembering  the  task  network  and  task 
allocation  to  types  of  crew  members. 
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Assume  for  the  sake  of  this  demonstration  that  the 
additional  three  seconds  to  complete  the  mission  is 
unacceptable.  Instead  of  delaying  the  start  of  the 
"Check  Chbr"  task,  we  can  eliminate  its  conflict  with 
other  tasks  by  reassigning  it  to  a  different  type  of 
crew  member.  The  procedure  for  the  reassignment  of 
tasks  to  types  of  crew  members  is  described  in  a  later 
section.  First,  however,  it  will  be  necessary  to  erase 
the  task  delay  that  was  just  instituted.  This  is  the 
subject  of  the  next  section. 


Zero  Delayed  Starts 

If  the  implemented  task  delay  is  determined  to  be 
inappropriate  as  a  template  modification  strategy,  the 
user  can  erase  all  task  delays  and  return  to  the 
original  set  of  task  start  times  by  using  the  "ZERO 
DELAYED  STARTS"  option.  To  access  "ZERO  DELAYED 
STARTS",  complete  the  following  steps: 

1.  Once  in  the  PERT/ GANTT  menu,  select  the 
"Deconfliction  Analysis"  option.  The 
"Deconflict ion  Frequencies"  table  will  be 
displayed.  Press  <Retum>  twice  to  make  the 
"Deconfliction  Features"  menu  appear. 

2.  Move  the  reverse  video  block  over  "Zero 
Delayed  Starts"  and  press  <Return>.  The 
"Zero  Delayed  Starts"  option  shown  on  the 
screen  will  blink  once  as  an  indication  that 
it  has  been  selected.  It  may  be  necessary  to 
press  <Retura>  more  than  once  to  get  this 
feedback. 

3.  As  with  any  change  to  the  crew  template, 
recalculate  the  critical  path. 

4.  Move  the  reverse  video  over  "Deconfliction 
Freq"  and  press  <Retum>.  The  "Check  Chbr" 
task  will  again  be  shown  as  being  in  conflict 
with  another  task.  Alternatively,  Press 
<Retum>  repeatedly  until  the  PERT/GANTT 
options  menu  is  displayed.  Then,  select  the 
"Conflict  Overlap"  option.  The  "Check  Chbr" 
task  will  be  shown  in  conflict  with  the 
"Unload  Gun"  task  for  crew  member  "Loader." 


Alternate  Assignment 

The  user  can  address  the  workload  problem  of  crew 
member  "Loader"  by  reassigning  one  or  more  of  the 
loader's  conflicting  tasks  to  another  type  of  crew 
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member.  To  reassign  tasks  to  alternative  crew  members, 
the  user  needs  to  take  the  following  actions: 

1.  While  in  the  “Choose  a  Deconfliction 
Feature”  menu,  select  the  “Alternate 
Assignment"  option. 

2.  The  screen  illustrated  in  Figure  35  will  be 
displayed.  This  is  the  same  screen  that  was 
displayed  when  the  “ASSIGN  RESOURCES  TO 
TASKS”  option  of  the  "BUILD  TEMPLATES 
OPTIONS"  menu  was  selected  (see  Figure  12) . 


RESOURCES  AVALABLE  TO  BE  ASSIGNED  TO  TASK  Check  Chbr 
SQUAD  LDR  GUNNER  LOADER 


I  There  are  Dt  nunibr  t4  R—ouree  LOADER  attignad  te  To»k _ Chech  Chbr  | 

RESOURCES  ASSIGNED  TO  TASK  Check  Chbr 


Figure  35.  Screen  allowing  assignment  of 
resources  to  tasks. 


A  quick  review  of  the  procedure  for  assigning 
types  of  crew  members  to  tasks  is  provided  in 
the  next  three  paragraphs. 

e  Press  the  <Ctrl-Arroir>  keys  to  change 
the  task  names  appearing  at  the  right 
end  of  the  rectangle. 

•  Press  the  arrow  keys  to  move  the  reverse 
video  over  the  list  of  types  of  crew 
members  available  to  perform  the 
designated  task  and  change  the  crew 
member  name  that  is  shown  at  the  center 
of  the  rectangle. 

•  Press  the  '+'  or  key  to  increase 
or  decrease  the  value  of  the  number 
shown  at  the  left  end  of  the  rectangle. 
The  number  shown  represents  how  many  of 
the  specified  type  of  crew  member  is 
assigned  to  perform  the  designated  task. 


To  continue  the  description  of  how  to  make 
alternative  assignments  to  eliminate 
conflicts,  the  user  should  enter  the 
following  "new"  assignments: 
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Number 

Crew  member 

Task 

Change 

ft^lt 

"Loader" 

"Check 

Chbr" 

To 

"Loader" 

"Check 

Chbr" 

and. 

Change 

MQ” 

"Squad  Ldr" 

"Check 

Chbr" 

To 

It  ^11 

"Squad  Ldr" 

"Check 

Chbr" 

In  other  words,  reassign  the  task  of  checking 
the  gun  chamber  from  the  crew  member  named 
loader  to  the  crew  member  named  squad  leader. 

3.  To  cause  the  alternate  assignments  just 
entered  to  be  implemented  the  critical  path 
must  be  recalculated.  The  user  should  press 
the  <Esc>  key  to  return  to  the  "Deconf liction 
Features"  menu,  and  select  the  "Calculate 
Critical  Path"  option.  (For  the  convenience 
of  the  user  this  option  is  available  from 
various  CRDS  menus . ) 

Important:  It  has  been  our  experience  that  reassigning 
a  task  from  one  type  of  crew  member  to  another  may 
cause  the  performance  time  entered  for  the  task  in  the 
"BUILD  TEMPLATE"  options  menu  to  be  assigned  a  value  of 
zero.  This  makes  sense  if  different  types  of  crew 
members  have  different  capabilities  for  performing  the 
designated  task.  Therefore,  it  will  be  necessary  for 
the  user  to  go  to  the  "ENTER  PERFORMANCE  MEASURES" 
option  of  the  "BUILD  TEMPLATE"  menu  to  check  that  the 
appropriate  performance  time  is  entered  for  the 
(re) assigned  task.  If  a  new  value  is  entered,  the  user 
must  remember  to  recalculate  the  critical  path. 

4.  Once  the  critical  path  is  recalculated,  it  is 
possible  to  examine  the  effects  of  the 
alternate  assignments.  If  the  "Conflict 
Adjustment"  or  the  "Deconfliction  Analysis" 
options  are  selected  from  the  PERT/GANTT 
menu,  the  user  will  see  that  "Check  Chbr"  and 
"Unload  Gun"  are  no  longer  on  the  list  of 
conflicting  tasks.  Alternately,  while  the 
GANTT  chart  will  show  these  two  tasks  as 
overlapping  in  time,  they  are  assigned  to 
different  types  of  crew  members  and  hence  are 
not  in  conflict.  This  point  is  also  evident 
since  these  two  tasks  are  no  longer  listed  in 
the  table  of  conflicting  tasks  shown  when  the 
"Conflict  Overlap"  option  is  selected  from 
the  PERT/ GANTT  options  menu. 
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Reassignment  of  Task  Sequence 

The  third  approach  described  in  this  User's  Guide 
for  addressing  workload  issues  in  a  crew  design  is  to 
redefine  the  sequence  in  which  tasks  must  be  performed. 
As  is  true  for  the  other  options,  changing  the  temporal 
relationship  among  required  tasks  may  affect  total 
mission  time.  Hence,  any  benefit  this  option  brings 
through  eliminating  conflict  may  be  offset  by  total 
mission  considerations.  Alternately,  a  change  in  task 
sequencing  may  benefit  the  total  mission  by  eliminating 
unnecessarily  long  delays  for  starting  the  performance 
of  some  required  tasks.  The  instructions  which  follow 
are  designed  to  show  how  features  of  the  CRDS  may  be 
used  in  an  attempt  to  reduce  total  mission  time.  (These 
actions  are  the  same  as  those  previously  described  in 
Part  Four  for  assigning  and  editing  task  relationships 
when  first  building  a  template.) 

1.  Press  <Bsc>  until  the  "MAIN  OPTIONS"  menu 
appears . 

2.  Once  in  the  "MAIN  OPTIONS"  menu,  select  the 
"BUILD  TEMPLATE"  option. 

3.  Select  the  "ASSIGN  TASK  RELATIONS"  option  of 
the  "BUILD  TEMPLATE  OPTIONS"  menu.  A  screen, 
such  as  the  one  illustrated  in  Figure  36  will 
be  displayed. 


CANDIDATES  TO  PRECEDE  TASK 

Attand  Sen  Ann.  Tgl  FIra  Ord  FIra  Gun  Load  gun 
Chaek  Chbr  Unload  Gun 


I  Currant  Talk  Noma  Chack  Chbr  ond  Numbar  07 

TASKS  TO  PRECEDE  CURRENT  TASK 
FIra  Gun 


Figure  36.  CRDS  screen  allowing  task 
sequence  to  be  modified. 


4.  Press  the  <CTRL-Arrow>  keys  to  change  the 

current  task  name  appearing  in  the  rectangle. 
As  the  current  task  name  changes,  the 
necessary  predecessor  tasks  initially 
assigned  for  each  selected  task  will  appear 
at  the  bottom  of  the  screen.  The  user  should 
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press  the  <CTRL-Arrow>  keys  until  ”Aim  Gun” 
appears  in  the  rectangle.  The  necessary 
predecessor  to  "Aim  Gun”  is  shown  to  be  "Fire 
Ord." 

For  the  sake  of  argument,  let  us  assume  that 
it  is  not  necessary  for  a  fire  order  to  be 
given  before  the  gun  is  aimed.  Instead,  the 
gunner  could  start  aiming  the  gvin  as  soon  as 
the  squad  leader  announced  the  target;  the 
gunner  would  then  fire  the  gun  upon  receiving 
the  fire  order.  By  deleting  "Fire  Ord”  as  a 
required  predecessor  to  "Aim  Gun”,  we  can 
test  the  effects  of  this  proposed  change. 

5.  To  add  a  "new"  predecessor  task,  press  the 
<Xrrov>  keys  to  highlight  the  desired 
predecessor  task  and  then  press  <Return>.  To 
delete  a  task  as  a  required  predecessor, 
press  the  <PgDn>  key.  This  action  moves  the 
reverse  video  bar  to  the  bottom  of  the 
screen.  Pressing  the  <Arrow>  keys 
highlights,  in  turn,  each  previously 
designated  predecessor  task.  Pressing 
<Retum>  when  a  predecessor  task  is 
highlighted  deletes  that  task  as  a 
predecessor. 

The  user  should  follow  these  instructions  to 
delete  "Fire  Ord"  as  a  necessary  predecessor 
task  for  the  "Aim  Gun"  task. 

6.  Press  <Esc>  twice  to  return  to  the  "BUILD 
TEMPLATE  OPTIONS"  menu,  and  again  to  return 
to  the  "MAIN  OPTIONS"  menu. 

7.  After  recalculating  the  critical  path,  the 
user  can  access  the  GANTT  chart  to  exeunine 
the  impact  of  the  new  task  relationships. 

From  the  GANTT  chart,  it  can  be  seen  that  one 
effect  of  removing  "Fire  Ord"  as  a  required 
predecessor  to  "Aim  Gun"  is  a  change  in  the 
tasks  in  the  critical  path.  The  new  critical 
path  is  comprised  of  only  three  tasks:  Load 
Gun,  Fire  Gun,  and  Unload  Gun.  This  change 
in  the  critical  path  caused  a  decrease  in  the 
total  mission  time  from  11  seconds  to  9 
seconds.  Hence,  a  change  in  operational 
procedures  that  changes  the  required 
relationship  among  tasks  can  affect  overall 
mission  completion  time. 
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Conclusion 


Part  Six  of  the  User's  Manual  describes  three 
different  techniques  for  addressing  workload  problems. 
These  techniques  required  the  user  to  (a)  delay  the 
start  times  of  specified  tasks,  (b)  make  alternate 
assignments  of  designated  tasks  to  specified  types  of 
crew  members,  and  (c)  redefine  the  constraints  in  task 
sequencing.  Each  of  these  approaches  to  addressing 
workload  issues  in  a  crew  design  was  illustrated  using 
the  template  built  by  the  user  and  named  "Example." 

The  next  part  of  the  User's  Guide  will  continue  the 
discussion  of  how  to  use  the  CRDS  by  describing 
applications  of  the  system  to  two  other  sample 
templates . 
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To  further  illustrate  how  to  use  the  CRDS  and 
interpret  its  output,  two  sample  applications  are 
presented  in  this  part  of  the  User's  Guide.  Both 
sample  problems  will  use  real  data  to  develop  CRDS 
templates.  The  first  sample  application  is  derived 
from  data  that  were  obtained  for  the  crew  of  a  weapon 
system.  The  second  daca  set  is  for  a  cell  of  personnel 
assigned  to  a  field  artillery  fire  direction  center 
(FDC) . 

Most  of  the  information  needed  to  build  the 
templates  was  obtained  through  an  analysis  of 
appropriate  Army  documents  and  with  the  assistance,  and 
ultimately  the  concurrence,  of  appropriate  subject 
matter  experts.  This  information  defined  the  types  of 
personnel  assigned  to  the  crew  or  cell,  the  tasks  which 
were  to  be  performed  to  accomplish  a  designated 
mission,  the  assignment  of  types  of  personnel  to 
perform  the  tasks,  and  any  constraints  on  the  sequence 
in  which  tasks  were  to  be  performed.  For  both  sample 
problems,  task  performance  time  data  were  obtained  from 
several  crews  or  cells  who  participated  in  field 
studies . 


Sample  Application  1  Weapon  System  Crew 

In  order  to  establish  a  crew  template  which 
incorporated  seme  serious  conflicts,  several 
adjustments  were  made  to  the  required  sequencing  of 
tasks  which  had  to  be  performed  by  the  crew  of  the 
weapon  system.  Consequently,  the  weapon  system,  its 
personnel  crew,  and  the  tasks  which  the  crew  members 
had  to  perform  are  not  identified.  Instead,  the  data 
and  the  template  will  apply  to  a  hypothetical  crew. 

The  mission  of  the  hypothetical  crew  requires  that 
19  tasks  be  performed  by  three  different  types  of  crew 
members.  For  this  sample  application  of  the  CRDS,  it 
is  stipulated  that  each  type  of  crew  member  is 
qualified  to  perform  only  those  tasks  to  which  it  is 
assigned.  Consequently,  the  assignment  of  types  of 
crew  members  to  tasks  cannot  be  altered. 

The  time  required  for  each  type  of  crew  member  to 
perform  the  tasks  to  which  it  is  assigned  has  been 
determined  empirically  and  is  unalterable.  These  task 
performance  times  are  given  in  Table  1  as  a  function  of 
the  task  and  type  of  crew  member.  Note,  that  with  the 
''xception  of  Tasks  4,  9,  and  13,  each  task  is  uniquely 
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assigned  to  only  one  of  the  crew  member  types.  Tasks  4 
and  9  are  performed  jointly  by  Crew  Member  Types  A  and 
B;  Task  13  is  performed  jointly  by  Crew  Member  Types  B 
and  C. 


Note,  that  if  the  19  tasks  were  performed  serially 
in  the  order  shown  in  Table  1,  the  total  time  required 
to  perform  all  19  tasks,  i.e.,  the  total  mission  time, 
would  be  124.4  seconds.  However,  in  this  sample 
application  it  is  stipulated  that  at  least  some  tasks 
may  be  performed  in  parallel .  It  is  furthermore 
stipulated  that  the  order  in  which  the  19  tasks  are  to 
be  performed  is  not  necessarily  dependent  upon  the 
exact  time  at  which  they  are  initiated  or  terminated, 
but  only  upon  certain  specified  and  required  task 


TABLE  1 


TASK  PERFORMANCE  TIME  (SECONDS) 

FOR  EACH  TASK  AND  CREW  MEMBER 
DURING  A  PRECISELY  DESIGNATED  MISSION 


Task 

Crew  Member 

Tvpe 

A 

B 

C 

1 

5.2 

— 

— 

2 

— 

6.0 

— 

3 

— 

9.9 

— 

4 

2.3 

2.3 

— 

5 

2.0 

— 

— 

6 

— 

19.1 

— 

7 

7.6 

— 

— 

'■ 

— 

4.0 

— 

9 

1.1 

1.1 

— 

10 

1.7 

— 

— 

11 

— 

18.0 

— 

12 

2.3 

— 

— 

13 

— 

15.2 

15.2 

14 

— 

— 

3.0 

15 

— 

— 

7.5 

16 

— 

— 

2.2 

17 

— 

— 

7.9 

18 

— 

— 

3.3 

19 

— 

—  — 

6.1 

relationships.  As  shown  in  Table  2,  certain  specified 
tasks  cannot  be  initiated  unless  and  until  other 
required  predecessor  tasks  have  been  completed.  An 
al+'ernative,  complementary  way  of  considering  this  same 
set  of  task  relationships  is  also  shown  in  Table  2.  In 
thxs  latter  case,  some  specified  tasks  must  be 
completed  before  other  successor  tasks  may  begin.  It 
will  be  assumed  that  the  task  relationships  illustrated 
in  Table  2  cannot  be  altered. 
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TABLE  2 


REQUIRED  TASK  RELATIONSHIPS 
DURING  A  PRECISELY  DESIGNATED  MISSION 


Task 

Predecessor 

Task 

Successor 

Task 

1 

none 

2, 4, 5, 9 

2 

1 

3 

3 

2 

6 

4 

1 

none 

5 

1 

none 

6 

3 

7 

7 

6 

8,10 

8 

7 

none 

9 

1 

none 

10 

7 

11 

11 

10 

12 

12 

11 

13 

13 

12 

14,16 

14 

13 

15 

15 

14 

18,19 

16 

13 

17 

17 

16 

18,19 

18 

15 

none 

19 

15 

none 

Building  and  Investigating  the  Characteristics  of  the  Crew 
Template 


The  CRDS  assists  the  user  in  investigating  the 
consequences  of  the  crew  data  set  defined  above.  After 
using  these  data  to  build  (and  save)  a  template  for 
this  seunple  application,  the  user  would  begin  the 
investigation  of  the  initial  crew  design  by  selecting 
the  option  of  the  CRDS  main  menu  which  calculates  the 
critical  path.  Table  3  shows  the  sequence  of  tasks  in 
the  critical  path  and  their  respective  start,  stop,  and 
duration  times.  The  stop  or  completion  time  of  the 
last  task  in  the  critical  task  sequence,  i.e..  Task  19, 
represents  the  minimum  time  required  to  complete  all 
tasks  in  the  overall  mission.  In  this  case,  the 
mission  performance  time  is  101.6  seconds,  22.8  seconds 
less  than  the  time  required  if  all  tasks  were  performed 
in  serial  order. 
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TABLE  3 


TASKS  IN  THE  CRITICAL  PATH  FOR  THE 
WEAPON  SYSTEM  CREW  SAMPLE  PROBLEM 


Task 

Time 

Start 

StOD 

Duration 

1 

0.0 

5.2 

5.2 

2 

5.2 

11.2 

6.0 

3 

11.2 

21.1 

9.9 

6 

21.1 

40.2 

19.1 

7 

40.2 

47.8 

7.6 

10 

47.8 

49.5 

1.7 

11 

49.5 

67.5 

18.0 

12 

67.5 

69.8 

2.3 

13 

69.8 

85.0 

15.2 

14 

85.0 

88.0 

3.0 

15 

88.0 

95.5 

7.5 

19 

95.5 

101.6 

6.1 

Figure  37  shows  one  result  produced  from  redrawing 
or  editing  the  initial  CRDS -generated  PERT  diagram  of 
the  relationship  aonong  all  19  tasks.  Each  line  in  the 
figure  is  l2d)eled  to  show  the  task  that  it  represents. 
The  ovals  or  "nodes"  shown  in  the  figure  represent  the 
beginning  and  end  of  each  task.  The  thicker  lines 
represent  the  critical  time  path.  Tasks  on  this  path 
are  critical  in  the  sense  that  they  must  be  performed 
on  schedule  and  can  tolerate  no  delay  without  adding  to 
the  total  mission  time.  Some  of  the  lighter  lines  are 
labelled  with  the  letter  "d."  These  lines  identify 
dummy  tasks  used  to  coordinate  the  performance  of  tasks 
whose  lines  would  otherwise  overlap  and  not  be 
separately  identifiable  in  the  graphic  presentation. 

The  dummy  tasks  are  also  used  to  connect  the  completion 
of  non-critical  tasks  to  the  node  that  represents  the 
end  of  the  mission. 

It  should  be  noted  that  while  the  PERT  diagram 
shown  in  Figure  37  is  useful  for  illustrating  the 
relationship  among  tasks,  the  relationship  shown  is  not 
necessarily  dependent  on  actual  task  or  mission 
performance  times.  The  vertical  distances  in  the  PERT 
representation  are  arbitrary;  vertical  space  is  used 
only  to  spread  out  the  task  lines  for  user  study. 
Likewise,  while  the  user  may  use  horizontal  distances 
in  a  PERT  representation  to  indicate  an  approximate 
task  performance  time  dimension,  there  is  no  fixed 
relationship  between  the  horizontal  placement  of  nodes 
and  the  start  or  completion  times  of  tasks.  The  user 
may  move  any  node  shown  in  a  PERT  diagram  any  distance 
in  any  direction  while  editing  the  graphic  portrayal  of 
the  task  network. 


78 


Figure  37 .  The  PERT  diagram  for  the  mission  essential 
tasks  of  the  weapon  system  crew  sample  problem. 


Figure  38  shows  a  graphic  portrayal  of  the  task 
network  which  combines  the  features  of  the  initial  PERT 
representation  with  a  timeline  placement.  In  this 
representation,  horizontal  distances  represent 
performance  time;  the  left  edge  of  each  oval  node  is 
located  at  the  earliest  possible  start  time  for  the 
task  which  follows  the  node.  The  user  may  edit  this 
time  dependent  PERT  representation  only  by  moving  nodes 
in  the  vertical  dimension.  Vertical  distances  have  no 


Figure  38.  The  timeline-based  PERT  diagram  for  the 
mission  essential  tasks  of  the  weapon  system  crew. 
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meaning  but  are  used  to  create  a  more  comprehensible 
diagram.  It  may  be  seen  in  Figure  38  that  there  are 
several  instances  in  which  multiple  tasks  are  performed 
during  the  same  or  in  overlapping  time  intervals.  If 
any  of  these  overlapping  tasks  are  assigned  to  the  same 
type  of  crew  member  there  may  be  an  instance  of 
conflict. 


MOTE:  The  timeline-baaed  PERT  diagrams  generated  by 
the  CRD8  are  missing  two  features  which  are  found  in 
the  PERT  diagrams  that  are  independent  of  perfoxrmance 
time.  First,  the  last  task  in  the  mission,  also  the 
last  task  in  the  critical  path,  is  not  present  in  the 
timeline-based  PERT.  Second,  the  lines  used  to 
represent  dummy  tasks  are  net  present  in  the  timeline- 
based  PERT. 


As  currently  programmed,  the  name  of  the  type  of 
crew  member  assigned  to  perform  each  task  is  not  shown 
in  a  PERT  diagram.  Also,  as  was  described  in  Part  Five 
of  this  User's  Guide,  the  purely  manual  editing  that  is 
necessary  to  create  perceptually  meaningful  and  useful 
PERT  diagrams  may,  in  turn,  require  considerable 
amounts  of  the  user's  time  (and  patience).  Both  of 
these  shortcomings  of  a  PERT  graphic  representations 
suggest  that  the  user  should  initially  use  other,  more 
fully  informative  and  automatically  generated  outputs 
of  the  CRDS  to  investigate  the  viability  of  a  crew 
database . 

Figure  39  shows  an  alternative  method  for 
graphically  displaying  the  relationship  among  all  19 
tasks.  This  graphic  representation  of  the  task 
network,  the  GANTT  chart,  is  generated  automatically 
and  displays  all  the  relevant  time  characteristics 
associated  with  each  task.  This  graphic  representation 
shows  also  that  there  are  instances  in  which  multiple 
tasks  are  performed  during  the  same  or  in  overlapping 
time  intervals.  To  determine  if  any  of  these 
overlapping  tasks  are  assigned  to  the  same  type  of  crew 
member  the  user  merely  needs  to  request  that  GANTT 
charts  be  created,  in  succession,  for  each  type. 
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Figure  40  shows  the  GANTT  chart  for  only  those 
tasks  performed  by  Crew  Member  Type  A.  This  figure 
clearly  shows  that  within  the  first  10  seconds  of  the 
mission,  Crew  Member  Type  A  is  required  to  perfoirm 
three  tasks  (Tasks  4,  5,  and  9)  during  the  same  time 
interval.  If,  for  any  reason,  these  three  tasks  cannot 
be  performed  simultaneously  by  this  type  of  crew 
member,  there  is  conflict.  To  resolve  this  particular 
conflict  without  making  any  changes  in  the  template, 
there  must  be  three  Type  A  crew  members  assigned  to  the 
crew,  one  to  perform  each  of  the  three  tasks. 


Figure  40.  The  GANTT  chart  for  the  mission  essential 
tasks  of  only  Crew  Member  Type  A. 
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Similarly,  by  separately  examining  the  GANTT  chart 
for  each  of  the  other  two  types  of  crew  members,  it  can 
be  determined  that  there  are  requirements  for  two  Type 
B  crew  members  and  two  Type  C  crew  members.  The 
specific  tasks  which  are  in  conflict  for  each  type  of 
crew  member  may  be  determined  from  either  the  GANTT 
chart  or  from  the  conflict  overlap  table. 

In  summary,  if  the  initially  created  crew  template 
represents  the  final  design  of  the  weapon  system  crew, 
there  would  be  a  requirement  for  seven  crew  members  to 
perform  the  19  mission  essential  tasks.  For  this 
sample  problem,  let  it  be  assumed  that  there  is  a  need 
to  make  modifications  in  these  crew  data  so  that  we  can 
meet  the  dual  objectives  of  minimizing  both  the  size  of 
the  crew  and  the  total  time  required  to  perform  all 
required  tasks.  Given  the  constraints  imposed  above 
for  modifying  these  data  (i.e.,  there  can  be  no 
reassignment  of  tasks  to  types  of  crew  members  and  no 
change  in  the  assignment  of  required  predecessor 
tasks) ,  the  only  way  to  achieve  the  desired  objectives 
is  to  modify  the  mission  timeline  by  delaying  the  start 
times  of  one  or  more  tasks. 

Modifying  the  Crew  Template  Without  Adding  to  Mission  Time 

The  CRDS  provides  the  user  with  the  capability  to 
reschedule  the  start  times  of  user-designated  tasks. 

The  tasks  most  likely  to  be  modified  first  are  those 
not  on  the  critical  path.  These  tasks  may  be  delayed 
up  to  their  allowable  slack  times  without  adding  to  the 
total  mission  time. 

The  tasks  to  be  delayed  were  determined  from  an 
examination  of  the  information  given  in  the  conflict 
frequencies  table.  This  information  indicates  which 
tasks  have  conflicts  which  can  be  resolved  without 
adding  to  the  mission  time  and  the  amounts  of  delay 
required  to  resolve  those  conflicts.  Of  course, 
removing  one  set  of  conflicts  often  creates  others,  so 
a  series  of  adjustments  generally  have  to  be  made. 
Furthermore,  depending  upon  the  particular  task 
conflict  which  is  resolved,  the  CRDS  may  not  always 
identify  the  next  conflict  to  be  resolved.  For  these 
reasons,  the  user  should  alternately  check  and  use  the 
information  presented  in  the  GANTT  charts  and  overlap 
tables  as  well  as  that  given  in  the  conflict  frequency 
tables. 

The  authors  of  the  User's  Guide  made  all  possible 
and  necessary  delays  in  tasks  not  on  the  critical  path 
over  a  series  of  10  successive  modifications  to  the 
template.  In  this  example  this  was  accomplished  by 
progressively  delaying  the  start  times  of  just  three 
tasks  (i.e..  Tasks  4 ,  8 ,  and  9 ) . 


82 


PART  SEVEN  —  SAMPLE  PROBLEMS 


IMPORTANT:  The  user  should  take  note  of  the  fact  that 

the  CRDS  does  not  cumulate  delays  in  the  start  time  of 
a  specific  task  over  successive  delays.  The  user  must 
manually  record  and  add  each  successive  delay  for  each 
task  to  the  previously  cumulated  total  delay  for  that 
task.  The  calculation  of  the  critical  path  for  a  crew 
template  that  has  been  modified  by  delays  in  the  start 
times  of  tasks  is  based  upon  task  start  times  that  are 
the  sum  of  the  original  task  start  times  and  the 
cumulated  delays  to  those  start  times. 

Figure  41  shows  the  GANTT  chart  which  graphically 
displays  the  relationship  among  all  19  tasks  after  all 
possible  and  necessary  delays  were  made  to  the  three 
tasks  identified  above.  This  GANTT  chart  fiand  those  for 
each  selected  type  of  crew  member)  show  that  after  some 
tasks  assigned  to  Crew  Member  Types  A  and  B  are  delayed 
by  as  much  as  86.2  seconds,  there  are  no  longer  any 
simultaneous  demands  for  conflicting  task  performance 
for  these  two  types  of  crew  members.  Hence,  only  one 
each  of  these  two  types  of  crew  members  is  required  to 
perform  the  tasks  assigned  them. 


NOTE:  Thm  user  should  also  note  that  the  slack  times 
for  non-critioal  tasks  shown  in  the  GANTT  chart 
are  not  recomputed  by  the  CRDS  after  the  start  times  of 
those  tasks  are  delayed.  Hence,  while  the  start, 
duration,  and  stop  times  shown  in  Figure  41  are  changed 
to  reflect  the  modifioations  made  to  the  start  times  of 
Tasks  4,  8,  and  9,  the  slacks  times  for  those  tasks  are 
not  similarly  adjusted.  The  slack  times  shown  in  the 
conflict  overlap  tables  are  also  not  adjusted.  This 
failure  to  adjust  slack  times  for  changes  made  to  the 
initial  template  database  is  a  fault  of  the  software. 
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Figure  41  also  indicates  that  the  adjustments  made 
thus  far  did  not  change  which  tasks  are  in  the  critical 
path  (tasks  timelines  shown  with  asterisks)  or  the 
total  mission  time  (shown  both  at  the  top  of  the  figure 
and  as  the  stop  time  of  Task  19) .  The  figure  does 
show,  however,  that  the  six  tasks  assigned  solely  to 
Crew  Member  Tj^e  C,  i.e..  Tasks  14  through  19,  are 
still  in  conflict  with  one  another. 


Modifying  the  Crew  Template  to  Further  Reduce  Manning  at  the 
Expense  of  Increasing  Mission  Time 

A  careful  examination  of  the  GANTT  chart  for  only 
Crew  Member  Type  C  indicates  that  the  tasks  that  are 
still  in  conflict  are  performed  after  the  first  80 
seconds  of  the  mission  duration.  As  a  result,  all 
slack  time  for  tasks  not  in  the  critical  path  that 
could  be  used  to  eliminate  these  conflicts  have  been 
"used  up."  Consequently,  any  further  attempts  to  reduce 
the  required  number  of  crew  members  will  involve 
delaying  the  start  times  of  tasks  on  the  critical  path. 
This,  of  course,  will  cause  an  increase  in  total 
mission  time  and  introduces  the  need  to  consider  the 
trade  off  between  manning  level  and  mission  duration. 

After  verifying  the  advice  available  in  the  GANTT 
chart  drawn  for  only  Crew  Member  Type  C  with  that  given 
in  the  overlap  and  conflict  frequency  tables,  two 
additional  modifications  were  made  to  the  crew  template 
for  this  sample  application.  First,  the  start  time  for 
Task  14  was  delayed  by  10.1  seconds.  Because  of  the 
task  relationships  required  for  this  sample  problem, 
delaying  Task  14  also  causes  similar  delays  for  Tasks 
15,  18,  and  19.  Second,  the  start  time  for  Task  19  is 
further  delayed  by  an  additional  3.3  seconds. 

The  results  of  these  latter  two  modifications  are 
evident  in  Figure  42.  This  figure  shows  the  new  GANTT 
chart  for  Crew  Member  Type  C  of  this  sample  problem. 
Close  examination  of  the  start  and  stop  times  for  tasks 
assigned  to  Crew  Member  Type  C  reveals  no  remaining 
conflicts  in  task  performance.  Hence,  only  one  of  this 
type  of  crew  member  is  required  to  perform  the  seven 
tasks  assigned  to  it.  The  new  critical  path,  however, 
reflects  an  increase  in  total  mission  performance  time 
from  101.6  to  115.0  seconds  (see  the  stop  time  of  the 
last  task  performed.  Task  19,  in  Figure  42) . 
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Figure  42.  The  GANTT  chart  for  only  the  tasks  assigned 
to  Crew  Member  Type  C  of  the  crew  after  delaying  the 
start  of  four  tasks  on  the  critical  path. 


Summary 


This  sample  problem  shows  that  the  CRDS  can  be 
used  as  an  aid  in  resolving  conflicts  caused  by  demands 
that  a  given  type  of  crew  member  simultaneously  perform 
multiple  tasks.  In  the  process  of  resolving  these 
conflicts,  it  also  is  shown  that  the  CRDS  can  be  an  aid 
for  reducing  the  total  number  of  crew  members  required. 
This  application  of  the  CRDS  developed  two  alternative 
definitions  of  the  crew  requirements.  In  one,  the  size 
of  the  crew  was  reduced  from  seven  crew  members  to 
four,  without  any  change  in  the  mission  performance 
time  of  101.6  seconds.  In  the  second,  the  size  of  the 
crew  was  further  reduced  to  three  crew  members  but  only 
by  increasing  the  mission  performance  time  by  13.4 
seconds . 

What,  if  any,  are  the  implications  of  delaying  the 
start  time  of  tasks  not  on  the  critical  path?  Will  the 
decrease  in  manning  requirements  from  seven  to  four 
offset  these  other  possible  outcomes  of  delaying  the 
performance  of  these  tasks?  Is  an  increase  in  mission 
performance  time  justifiable  in  order  to  reduce  manning 
requirements  by  one?  The  implications  of  these 
potential  tradeoffs,  and,  indeed,  the  impact  of  any 
alternative  templates  developed  using  the  CRDS  require 
further  investigation,  especially  in  an  operational 
context. 
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Sample  Application  2  —  Fire  Direction  center  Cell 

This  sample  application  of  the  CRDS  is  for  a  cell 
of  personnel  that  are  assigned  to  a  field  artillery 
fire  direction  center  (FDC) .  The  data  required  to 
build  a  template  for  this  sample  application  have 
already  been  entered  into  the  CRDS  by  the  authors  to 

develop  the  file  named  FDC _ .SRD.  The  user  can 

access  this  cell  template  through  the  files  directory 
menu. 


The  application  of  the  CRDS  to  organizational 
building  blocks  other  than  only  the  personnel  assigned 
to  a  crew-served  weapon  system  is  an  important 
extension  of  the  tool.  Building  and  studying  a 
template  for  the  team  or  cell  which  constitutes  a  FDC 
represents  a  departure  from  the  typical  crew  in  at 
least  two  ways. 

•  The  cell  is  not  servicing  materiel  to  generate 
combat  power. 

•  The  cell  is  comprised  of  personnel  that  are 
widely  dispersed  in  battle  deployment;  they 
must  communicate  by  radio. 

The  objective  for  describing  this  particular 
sample  application  is  not,  as  was  the  case  with  the 
first  sample  application,  to  show  how  the  CRDS  can  be 
used  to  define  a  cell  with  a  smaller  manning 
requirement.  As  will  be  seen  below,  the  template  for 
this  cell  is  such  that  only  one  of  each  type  of 
personnel  is  required.  Rather,  the  objective  of  this 
sample  problem,  other  than  to  merely  demonstrate  the 
building  and  examination  of  a  cell  template,  is  to  show 
how  the  CRDS  can  be  used  to  identify  which  tasks  or 
personnel  would  benefit  most  from  enhancements  in 
hardware  or  software,  from  a  change  in  how  the  tasks 
might  be  performed,  and  in  assignment  of  tasks  to 
personnel . 

The  mission  for  the  manual  FDC  used  in  this  sample 
application  was  to  place  on-call  suppressive  fire 
against  a  target  whose  location  was  an  offset  from  a 
pre-calculated  index  or  registration  point.  The 
mission  began  with  the  initial  receipt  of  target 
information  from  a  forward  observer  and  ended  with 
successful  transmission  of  the  shift  mission  to  the 
battery  of  155-mm  Howitzers.  The  cell  consists  of  five 
types  of  personnel:  a  fire  direction  officer  (FDO) ,  a 
computer  (CMPTR) ,  a  chart  operator ( CHRTO ) ,  a  forward 
obser\'er  (OBSVR)  ,  and  a  set  of  guns  located  at  a 
batteiry  location  (BTRY) . 
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NOTE:  In  this  particular  sample  application,  the 
■'computer”  is  a  human  being,  but  a  purely  hardware-  and 
software-based  computer  could  also  be  envisioned  as  a 
resource  assigned  to  this  cell,  perhaps  with  a  hiiman 
assigned  to  operate  the  computer.  Assigning  non-human 
resources  to  the  cell  would  constitute  a  third  way  that 
the  template  of  a  cell  could  differ  from  that  of  a 
typical  crew. 

Table  4  identifies  the  23  tasks  which  must  be 
performed  by  the  FDC  to  accomplish  its  mission.  Table 
5  shows  the  performance  times  for  each  task  as  a 
function  of  the  type  of  personnel  assigned  to  perform 
the  task.  These  performance  time  data  were  obtained 
during  tests  conducted  in  a  field  environment.  The 
constraints  on  the  order  in  which  tasks  could  be 
performed  are  in  Table  6,  which  identifies  required 
predecessor  and  successor  tasks  for  each  mission 
essential  task.  Taken  together,  the  data  in  these 
three  tables  are  sufficient  to  build  a  template  for 
this  cell  performing  the  prescribed  mission.  (See  the 

data  file  named  FDC _ .SRD  in  the  CRDS  files 

directory. 


TABLE  4 


MISSION  ESSENTIAL  TASKS  OF  THE  FDC  CELL 


Task 


1  ISSUE  CALL 

2  RDBK  CALL 

3  I DENT  RP 

4  RDBK  RP 

5  TGT  COORD 

6  RDBK  COORD 

7  DESC  TGT 

8  RDBK  DESC 

9  FIORD  FDC 

10  MSG  TO  OBS 

11  FM  GUN 

12  RDBK  FM 

13  FIORD  GUN 

14  RDBK  FIORD 

15  PLOT  RG 

16  RDBK  RG 

17  CHT  DEFL 

18  RDBK  DEFL 

19  FD/CD/DEFL 

20  RDBK  DEFL 

21  SITE 

22  QUADRANT 

23  RDBK  QUAD 


Description _ 

Issues  call  for  fire 
Receives  &  reads  back  call  for  fire 
Identifies  registration  point 
Receives  &  reads  back  registr  point 
Announces  target  coordinates 
Receives  &  reads  back  coordinates 
Describes  target 

Receives  &  reads  back  tgt  descrip 
Issues  fire  order 
Determines  &  transmits  the  MTO 
Transmits  fire  mission  alert  to  btry 
Receives  &  reads  ha  :k  fire  msn  alrt 
Transmits  fire  order  to  the  battery 
Receives  &  reads  back  fiord  to  cmptr 
Plots  target  &  announces  chart  range 
Receives  &  reads  back  target  range 
Announces  chart  deflection 
Receives  &  reads  back  chart  defl 
Cmpt  data-change  to  cmd-defl  to  btry 
Receives  &  reads  back  deflection 
Computes  site  &  announces  to  cmptr 
Computes  &  transmits  quad  to  btry 
Receives  &  reads  back  quadrant 
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TABLE  5 


TASK  PERFORMANCE  TIME  (SECONDS) 
FOR  EACH  TASK  AND  TYPE  OF  PERSONNEL 
DURING  THE  FDC  MISSION 


Task 

TvTDe 

of  Personnel 

OBSVR 

FDO 

CMPTR 

BTRY 

CHRTO 

1 

2.45 

— 

— 

— 

— 

2 

— 

2.22 

— 

— 

— 

3 

3.27 

— 

— 

— 

— 

4 

— 

2.39 

— 

— 

— 

5 

6.21 

— 

— 

— 

— 

6 

— 

6.95 

— 

— 

— 

7 

4.36 

— 

— 

— 

— 

8 

— 

1.99 

— 

— 

— 

9 

— 

2.28 

— 

— 

— 

10 

— 

2.07 

— 

— 

— 

11 

— 

— 

2.12 

— 

— 

12 

— 

— 

— 

1.42 

— 

13 

— 

— 

1.52 

— 

— 

14 

— 

— 

— 

1.80 

15 

— 

— 

— 

— 

39.78 

16 

— 

— 

2.42 

— 

— 

17 

— 

— 

— 

6.78 

18 

— 

— 

2.67 

— 

— 

19 

— 

— 

18.79 

— 

— 

20 

— 

— 

— 

1.65 

— 

21 

— 

18.64 

— 

— 

— 

22 

— 

— 

8.82 

— 

— 

23 

—  — 

—  — 

—  — 

1.25 

—  — 
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TABLE  6 


REQUIRED  TASK  RELATIONSHIPS 
DURING  A  FDC  MISSION 


Task 

Predecessor 

Task 

Successor 

Task 

1 

ISSUE  CALL 

none 

2,11 

2 

RDBK  CALL 

1 

3 

3 

IDENT  RP 

2 

4,15 

4 

RDBK  RP 

3 

5 

5 

TGT  COORD 

4 

6 

6 

RDBK  COORD 

5 

7 

7 

DESC  TGT 

6 

8 

8 

RDBK  DESC 

7 

9 

9 

FIORD  FDC 

8 

10,13 

10 

MSG  TO  OBS 

9 

none 

11 

FM  GUN 

1 

12 

12 

RDBK  FM 

11 

13 

13 

FIORD  GUN 

9,12 

14 

14 

RDBK  FIORD 

13 

none 

15 

PLOT  RG 

3 

16,21 

16 

RDBK  RG 

15 

17 

17 

CHT  DEFL 

16 

18 

18 

RDBK  DEFL 

17 

19 

19 

FD/CD/DEF 

18 

20 

20 

RDBK  DEFL 

19 

22 

21 

SITE 

15 

22 

22 

QUADRANT 

20,21 

23 

23 

RDBK  QUAD 

22 

none 

The  CRDS  permits  the  user  to  quickly  examine  these 
data  in  a  variety  of  different  formats.  The  network  of 
tasks  and  the  critical  path  are  shown  in  the  PERT 
diagram  illustrated  in  Figure  43.  Table  7  shows  the 
timing  of  tasks  in  the  critical  path.  It  may  be  seen 
that  thirteen  of  the  23  tasks  are  on  the  critical  path 
and  that  the  time  required  to  complete  the  designated 
mission  is  98.7  seconds. 

MOTE:  The  horiiontal  dimension  of  the  PERT  diagram 
shown  in  Figure  43  has  been  constructed  to  approximate 
the  task  and  mission  performance  timeline.  The  authors 
first  developed  the  timeline-based  PERT  diagram  and 
used  the  spatial  relationships  among  the  nodes  in  that 
diagram  to  draw  the  diagram  shown  in  Figure  43.  The 
advantage  of  following  these  procedures  is  that  it 
allows  the  user  to  draw  a  task  line  for  the  last  task 
in  the  critical  path  as  well  as  various  dummy  task 
lines. 
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Note  that  six  of  the  tasks  on  the  critical  path 
share  the  abbreviation  "RDBK.”  This  abbreviation 
indicates  that  a  designated  type  of  personnel  receives 
and  then  reads  back  portions  of  the  information  flow. 
Timing  for  these  six  tasks  total  about  12  seconds  and 
is  a  price  intentionally  paid  for  reliability  in 
'•manual”  fire  direction.  The  CRDS  could  be  used  to 
quantify  the  effectiveness  gained  by  automating  these 
tasks. 


TABLE  7 


FDC  TASKS  ON  THE 
CRITICAL  PATH 


TASK 

START 

STOP 

DURATION 

1 

ISSUE  CALL 

0.0 

2.4 

2.4 

2 

RDBK  CALL 

2.4 

4.7 

2.2 

3 

IDENT  RP 

4.7 

7.9 

3.3 

4 

RDBK  RP 

7.9 

10.3 

2.4 

5 

TGT  COORD 

10.3 

16.5 

6.2 

15 

PLOT  RG 

16.5 

56.3 

39.8 

16 

RDBK  RG 

56.3 

58.7 

2.4 

17 

CHRT  DEFL 

58.7 

65.5 

6.8 

18 

RDBK  DEFL 

65.5 

68.2 

2.7 

19 

FD/CD/DEF 

68.2 

87.0 

18.8 

20 

RDBK  DEFL 

87.0 

88  6 

1.6 

22 

QUADRANT 

88.8 

97.4 

8.8 

23 

RDBK  QUAD 

97.4 

98.7 

1.2 
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The  relationship  among  task  performance  times  is 
displayed  in  order  of  earliest  stairt  times  in  the  GANTT 
chart  shown  in  Figure  44.  The  longest  task  may  be 
quickly  seen  to  be  Task  Number  15,  plotting  of  the 
range  to  the  target;  it  consumes  39.8  seconds  and  lies 
on  the  critical  path.  Improving  the  performance  time 
of  that  one  task  could  significantly  decrease  the  time 
required  to  perform  the  designated  mission.  A  decrease 
in  mission  performance  time  would  increase  the  number 
of  fire  missions  that  could  be  managed  by  a  fire 
direction  team  within  a  given  time  window. 


Summary 


second  sample  problem  shows  that  the  CRDS  can 
be  applied  to  a  cell  of  personnel  (and  equipment)  whose 
pu^ose  IS  not  merely  to  service  a  materiel  system,  but 
rather  to  perform  a  set  of  interrelated  tasks  which 
muet  be  performed  to  accomplish  some  specified 
function.  The  functions  assigned  to  a  cell  are  often 
required  to  give  some  other,  often  higher  echelon  unit 
a  mission  essential  capability.  This  second  sample 
problem  also  demonstrates  that  the  CRDS  can  be  used  as 
an  aid  to  evaluating  various  attributes  of  the  unit 
under  study.  That  evaluation  can,  in  turn,  allow  the 
user  to  project  desirable  improvements  in  the 

personnel  (and  equipment) 
assigned  to  the  cell  as  well  as  operational  and 
organizational  procedures  for  employing  those  types  of 
resources  to  improve  the  overall  performance 
capabilities  of  the  unit. 
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PART  SEVEN  —  SAMPLE  PROBLEMS 


A  Final  Suggestion  for  Future  Applications  of  the  CRDS 

Both  of  the  sample  problems  described  in  this  part 
of  the  User's  Guide,  as  well  as  the  template  named 
"Example"  that  was  developed  and  analyzed  in  earlier 
parts  of  the  Guide,  assume  that  the  unit  under  study 
performs  a  fixed  set  of  tasks  repetitively  and  in  a 
recurring,  cyclic  manner  in  the  course  of  performing 
its  mission.  This  assumption  concerning  the  nature  of 
the  conduct  of  task  and  mission  performance  is  not 
necessary  if  the  user  wishes  to  apply  the  CRDS. 

Indeed,  very  many  important  missions  performed  by  many 
types  of  organizational  units  will  not  conform  to  the 
conditions  dictated  by  this  assumption.  Some  of  the 
more  interesting  and  useful  types  of  crew  or  cell 
design  must  address  unit  missions  comprised  of  tasks 
whose  performance  requirements  are  probabilistic  rather 
than  deterministic. 

However,  these  types  of  potential  applications 
raise  a  problem.  Namely,  how  does  one  define,  build, 
and  analyze  a  unit  model  or  template  when  the  mission 
of  the  organizational  unit  is  not  comprised  of  tasks 
which  are  performed  in  a  recurring,  deterministic 
sequence  or  network?  It  is  proposed  that  there  are 
three  approaches  that  the  user  can  take.  Each  is 
briefly  described  below.  While  the  CRDS  may  not  be 
directly  applicable  to  the  first  approach  described,  it 
is  very  appropriate  for  the  other  two. 

For  one  approach,  the  entire  modelling  process 
could  be  converted  into  a  Monte  Carlo  simulation 
wherein  the  population  of  alternative  task  sequence 
combinations  and  times  are  sampled  over  time.  This 
approach  would  essentially  require  the  small  unit 
designer  to  use  a  model  building  aid  other  than  the 
CRDS. 


While  there  are  such  aids  available,  there  is 
ample  reason  to  believe  that  using  these  tools  would 
inevitably  create  three  conditions  that  could  be 
contrary  to  the  goals  of  the  user;  (a)  it  would 
require  a  much  more  extensive  data  collection  effort 
and  a  more  detailed  level  of  knowledge  about  the  system 
and  functions  under  study,  (b)  it  would  demand  heroic 
assumptions,  and  (c)  it  would  devastate  the  run  time 
required  to  analyze  a  unit's  organizational  structure. 
Any  one  or  more  of  these  conditions  could  place 
unacceptable  burdens  on  any  potential  user,  especially 
during  early  stages  in  the  development  of  new  materiel 
or  organizational  concepts. 

In  a  second  approach,  the  user  could  use  a  mission 
profile  representation  of  the  crew  or  cell  of  interest 
performing  at  maximum  stress  levels.  If  the  crew  or 
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cell  were  designed  to  meet  this  maximim  level  of 
operational  demand,  it  could  be  assumed  that  the  design 
would  also  establish  a  viable  organizational  structure 
for  less  stressing  sets  of  conditions. 

The  third  approach  to  designing  units  whose 
missions  are  comprised  of  probabilistic  rather  than 
deterministic  task  relationships  relies  on  the 
capability  the  CRDS  provides  to  the  user  for  modifying 
an  initial  crew  or  cell  template.  Since  it  is  so  quick 
and  simple  to  create  or  redo  alternative  task  networks 
when  using  the  CRDS,  the  user  can  replace  an  action 
choice  (i.e.,  an  action  that  forms  a  branch  in  the  task 
network)  with  only  simple  actions.  For  example,  rather 
than  entering  into  the  network  an  action  choice  for 
either  engaging  or  not  engaging  a  potential  target,  the 
user  can  create  a  database  for  engaging  a  target  and 
another  database  for  not  engaging  a  target.  Since  the 
user  normally  has  to  compare  the  alternative  branches 
of  a  task  performance  network  in  detail  anyway,  this 
third  approach  has  much  appeal. 
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